同一服务器某SQL Server数据库查询超时但副本正常，该如何排查？

• 查询执行计划低效：生产库的统计信息过期、索引碎片过高，会触发查询优化器生成针对该组记录的低效执行计划，执行耗时远超默认阈值。而数据库副本的统计信息、碎片状态与生产库存在差异，会生成更优的执行计划，因此查询可以正常返回。你可以在生产库抓取该查询的实际执行计划，与副本库的执行计划做对比验证。
• 行锁/事务阻塞：生产环境中该组特定记录可能被其他未提交的长事务锁定，导致你的查询长时间等待锁释放触发超时。副本库一般没有高频写入操作，不存在阻塞场景，因此查询可以正常执行。你可以通过SQL Server的活动监视器、sp_who2存储过程或者sys.dm_tran_locks系统视图查询执行时刻的阻塞会话。
• SqlCommand超时阈值配置不足：该组记录的查询本身需要的执行时间超过了你代码中配置的SqlCommand.CommandTimeout阈值（默认值为30秒），注意不要和数据库连接超时参数ConnectionTimeout（默认值为15秒）混淆，你可以针对性调高该查询操作的超时阈值做验证。
• 生产库资源瓶颈：生产库的CPU、内存、磁盘IO使用率在你查询该组记录时刚好处于高负载状态，无法及时分配资源处理该查询。副本库的业务负载更低，因此可以快速响应。你可以查看SQL Server的性能计数器，确认查询执行时刻的服务器资源占用情况。
• 参数嗅探问题：如果你的查询使用了参数化SQL，SQL Server可能缓存了不适配当前查询参数的执行计划，导致特定参数的查询效率骤降。副本库没有对应的缓存执行计划，会重新生成适配的计划，因此可以正常执行。你可以通过添加OPTION (RECOMPILE)查询 hint 验证是否为参数嗅探问题。
• 数据集体积过大：如果该组记录返回的行数、单条数据大小远高于其他记录组，DataAdapter.Fill方法在内存中构造DataSet的过程耗时超过超时阈值，也会触发该报错。你可以先在数据库端直接执行对应查询，统计返回结果的总数据量做排查。

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