遇到这种同一段存储过程在不同服务器上性能天差地别的情况，我给你梳理几个实际工作中常用的排查方向和优化思路，一步步来定位问题：

一、先排查两台服务器的环境差异 #

硬件和配置的不同往往是性能差异的根源：

• 硬件配置对比：检查CPU核心数、内存大小、磁盘类型（SSD vs HDD），尤其是磁盘IO——慢服务器如果用的是老旧机械盘，多字段搜索的IO开销会被放大。另外可以看看SQL Server的内存分配，执行 sp_configure 'max server memory'，确认慢服务器有没有给SQL Server分配足够的内存。
• SQL Server版本与补丁：不同版本的查询优化器逻辑有差异，旧版本可能存在性能bug，对比两台服务器的版本号，看看慢服务器是不是没打最新的累积更新。
• 数据库配置检查：
  • 自动统计信息是否开启：执行 SELECT is_auto_create_stats_on, is_auto_update_stats_on FROM sys.databases WHERE name = '你的数据库名';，统计信息过时会让优化器生成错误的执行计划。
  • 隔离级别：慢服务器会不会用了更严格的隔离级别（比如SERIALIZABLE），导致锁竞争或阻塞？可以用 DBCC USEROPTIONS 查看当前隔离级别。

二、对比两台服务器的执行计划 #

执行计划是定位性能问题的核心：

• 在慢服务器上运行存储过程时，生成实际执行计划（SSMS里按Ctrl+M），和快服务器的执行计划对比，重点看这几点：
  • 是不是走了全表扫描？快服务器用了索引但慢服务器没用到？
  • 有没有出现键查找（Key Lookup）或RID查找（RID Lookup）？这意味着索引没有覆盖所有需要的字段，导致额外的IO。
  • 连接运算符是不是不一样？比如快服务器用了嵌套循环，慢服务器用了哈希匹配（数据量变大后哈希匹配可能更慢）。
• 更新慢服务器的统计信息试试：执行 UPDATE STATISTICS dbo.client WITH FULLSCAN;，过时的统计信息是执行计划变差的常见原因。

三、针对多字段搜索优化索引 #

你说已经建了索引但没用，大概率是索引的类型或结构不对：

• 避免前缀模糊匹配的索引失效：如果你的搜索是 WHERE col1 LIKE '%关键词%' OR col2 LIKE '%关键词%' 这种后缀/全模糊匹配，普通的单列索引会直接失效，因为优化器没法利用索引的有序性。
• 改用全文索引：对于多字段的模糊搜索，全文索引是最优解，它专门针对文本搜索做了优化，比LIKE效率高几个数量级。可以给client表的搜索字段创建全文目录和全文索引。
• 优化索引覆盖性：如果是精确匹配或前缀匹配（LIKE '关键词%'），可以创建复合索引，把最常用的搜索字段放在前面，并且包含查询需要的其他字段（比如 CREATE NONCLUSTERED INDEX IX_Client_Search ON dbo.client(col1, col2) INCLUDE(col3, col4);），避免键查找。
• 清理索引碎片：如果慢服务器的索引碎片过多，会降低索引效率。执行 SELECT * FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.client'), NULL, NULL, 'DETAILED'); 查看碎片率，超过30%就重建索引：ALTER INDEX ALL ON dbo.client REBUILD;，10%-30%可以重组：ALTER INDEX ALL ON dbo.client REORGANIZE;

四、优化存储过程的查询逻辑 #

有时候问题出在查询本身：

• 拆分OR条件为UNION ALL：如果是多字段的OR搜索，比如 WHERE col1 LIKE '%x%' OR col2 LIKE '%x%'，可以拆成两个查询用UNION ALL合并：

  SELECT * FROM dbo.client WHERE col1 LIKE '%x%'
  UNION ALL
  SELECT * FROM dbo.client WHERE col2 LIKE '%x%'
  

  这样优化器可以分别利用每个字段的索引（如果有的话），比单个OR查询效率更高。
• 避免在搜索字段上做函数操作：比如 WHERE UPPER(col1) = 'KEYWORD' 会导致索引失效，改成在插入数据时统一存储为大写，或者用 COLLATE SQL_Latin1_General_CP1_CS_AS 来实现大小写敏感的匹配。
• 简化不必要的逻辑：检查存储过程里有没有多余的JOIN、子查询，或者重复的计算，比如可以把重复用到的子查询改成CTE或临时表。

五、其他排查点 #

• 检查锁与阻塞：慢的时候用 sp_who2 或 SELECT * FROM sys.dm_tran_locks 看看有没有会话被阻塞，是不是有其他长时间运行的事务占用了client表的锁。
• 参数嗅探问题：如果存储过程的参数变化大，第一次执行生成的执行计划不适合后续参数，会导致性能波动。可以试试重新编译存储过程：EXEC sp_recompile '你的存储过程名';，或者在查询末尾加 OPTION (RECOMPILE) 让优化器每次生成新的执行计划。

内容的提问来源于stack exchange，提问作者Teo