Parameter sniffing 是 SQL Server 默认行为，指优化器基于首次参数值生成并缓存执行计划，导致后续不同参数值时性能骤降；可通过 OPTION(RECOMPILE)、局部变量或 OPTIMIZE FOR 缓解。
不是服务器配置高就一定快——生产环境比测试环境慢，大概率是 Parameter sniffing、NUMA 内存访问不均或统计信息陈旧导致的执行计划“误判”，而不是硬件或代码本身有问题。
Parameter sniffing 导致执行计划固化错配
SQL Server 存储过程第一次执行时，会根据传入参数生成并缓存执行计划。如果首次调用用了小数据量参数（比如查昨天的数据），优化器生成了嵌套循环 + 索引查找的计划；后续用大数据量参数（比如查整月汇总）再调用，仍复用该计划，就会严重低效。
- 现象：
sp_whoisactive显示 CPU 高但逻辑读远超预期，sys.dm_exec_query_stats中同一存储过程的avg_logical_reads波动极大 - 验证方法：在存储过程中加
WITH RECOMPILE临时重编译，若速度恢复正常，基本可锁定此问题 - 稳妥解法：改用
OPTION (RECOMPILE)在关键语句后（如SELECT或INSERT），或用局部变量绕过嗅探：DECLARE @local_date VARCHAR(30) = @THEDATE; WHERE date_col = @local_date
NUMA 架构下跨节点内存访问拖慢查询
生产服务器用了多路 CPU + NUMA 架构，但 SQL Server 实例未正确绑定到单个 NUMA 节点，或某次查询申请的内存超过单节点容量，被迫跨节点分配——物理距离拉长，延迟上升。
- 现象：
sys.dm_os_nodes查到node_state_desc含ONLINE DAC，且memory_node_id分布不均；sys.dm_os_memory_clerks中single_pages_kb在多个节点间剧烈波动 - 检查命令：
SELECT memory_node_id, pages_kb FROM sys.dm_os_memory_clerks WHERE type = 'MEMORYCLERK_SQLBUFFERPOOL' - 应对方式：在 SQL Server 启动参数中添加
-g2048（预留内存防跨节点），或通过 Windows 亲和性设置将实例绑定到特定 NUMA 节点（需重启服务）
统计信息过期让优化器“看走眼”
测试库数据量小、更新少，统计信息准；生产库每日大批量写入，但 auto update statistics 没触发（比如 rowmodctr 变化未达阈值），优化器仍按旧分布估算行数，选错索引甚至全表扫描。
- 现象：
EXPLAIN显示rows和filtered与实际结果偏差 10 倍以上；sys.dm_db_stats_properties中last_updated是几周前 - 紧急修复：
UPDATE STATISTICS dbo.YourTable WITH FULLSCAN, NORECOMPUTE（慎用于大表） - 长期策略：对高频变更表启用
ASYNC_STATISTICS_UPDATE = ON，并定期跑sp_updatestats（注意它不更新列级统计）
真正卡住性能的，往往不是某条语句写得差，而是执行计划在不同环境下的“适应性失灵”。尤其当生产数据分布、并发压力、硬件拓扑和测试环境存在系统性差异时，光看代码和索引没用——得进 sys.dm_exec_cached_plans 翻执行计划，拿 query_hash 对比两环境的实际计划 XML 差异，才能揪出那个被忽略的 parameterization 或 memory_grant 细节。
