执行计划失配是主因：参数嗅探、统计信息陈旧或硬件拓扑（如NUMA/缓冲池配置）不匹配导致优化器生成并复用低效计划；需通过sys.dm_exec_query_stats等视图分析plan_handle复用率与IO波动，结合OPTION(RECOMPILE)验证及UPDATE STATISTICS等手段修复。
不是代码写错了，大概率是执行计划在生产环境“认错人”了——参数值分布、统计信息、硬件拓扑三者之一或全部失配，导致优化器生成了低效计划并反复复用。
查执行计划是否被错误复用
SQL Server 的 sys.dm_exec_query_stats 是第一线索：同一 plan_handle 的 execution_count 高，但 total_logical_reads 或 avg_logical_reads 波动剧烈（比如从 500 跳到 200 万），基本锁定参数嗅探（Parameter Sniffing）问题。MySQL 则看 performance_schema.events_statements_summary_by_digest 中相同 digest 的 avg_timer_wait 和 avg_rows_affected 是否离散。
验证方式：
- SQL Server：在存储过程中关键语句后加 OPTION (RECOMPILE)，如果速度立刻恢复，就是它；
- MySQL：把过程里那条慢 SQL 单独拎出来，用真实参数值执行 EXPLAIN FORMAT=TRADITIONAL，再对比存储过程内直接用参数变量时的 EXPLAIN 结果——若后者 key_len 异常小或 type 退化为 ALL，说明隐式转换或类型不匹配已让索引失效。
确认统计信息是否陈旧
测试库数据少、更新少，统计信息准；生产库每日大批量写入，但 innodb_stats_auto_recalc 可能未触发（尤其当 rowmodctr 变化未达阈值），优化器仍按旧分布估算行数，选错索引甚至全表扫描。
实操建议：
- 查 SHOW INDEX FROM table_name 看 Cardinality 是否远低于实际行数；
- 查 SELECT * FROM sys.dm_db_stats_properties(OBJECT_ID('dbo.YourTable'), INDEXPROPERTY(OBJECT_ID('dbo.YourTable'), 'YourIndex', 'IndexId'))（SQL Server）或 INFORMATION_SCHEMA.STATISTICS（MySQL）确认 last_updated 时间；
- 紧急修复：SQL Server 执行 UPDATE STATISTICS dbo.YourTable WITH FULLSCAN，MySQL 执行 ANALYZE TABLE your_table；
- 长期策略：对高频变更表启用 ASYNC_STATISTICS_UPDATE = ON（SQL Server）或调大 innodb_stats_persistent_sample_pages（MySQL）。
检查 NUMA 或内存分配是否异常
生产服务器多路 CPU + NUMA 架构，但 SQL Server 实例未绑定到单个 NUMA 节点，或某次查询申请内存超过单节点容量，被迫跨节点访问——物理距离拉长，延迟上升。MySQL 虽无显式 NUMA 概念，但 innodb_buffer_pool_size 过小（如默认 128MB）在 50 万+ 行表上会频繁回表、刷页，本地/测试库因无人争抢缓冲池而表现良好。
现象：
- SQL Server：sys.dm_os_nodes 中 node_state_desc 含 ONLINE DAC，且 memory_node_id 分布不均；sys.dm_os_memory_clerks 中 single_pages_kb 在多个节点间剧烈波动；
- MySQL：SHOW VARIABLES LIKE 'innodb_buffer_pool_size' 显示值远小于表数据大小（如 160MB 表只配 128MB 缓冲池）。
应对：
- SQL Server：启动参数加 -g2048 预留内存防跨节点，或 Windows 亲和性设置绑定 NUMA 节点（需重启）；
- MySQL：调大 innodb_buffer_pool_size 至物理内存 70%~80%，避免频繁磁盘 IO。
警惕 SET 选项不一致导致计划隔离
哪怕两个存储过程一字不差，只要一个连接默认开了 SET ARITHABORT ON，另一个没开，SQL Server 就认为它们是不同上下文，各自编译、各自缓存。结果就是：同一个过程反复进缓存，usecounts 始终为 1，看起来快了，其实每次都在重编译——CPU 白烧，性能不稳。
排查：
- 执行 SELECT SESSIONPROPERTY('ARITHABORT')，返回 1 表示 ON；
- ORM（如 Entity Framework）默认发 SET ARITHABORT ON，SSMS 默认 OFF，这就是为什么 SSMS 测试快、上线就慢；
- 统一方案：EF 连接字符串加 ARITHABORT=true，或应用层统一设 SET ARITHABORT ON。
真正卡住人的，往往不是哪一行 SQL 写得不好，而是执行计划在生产环境里悄悄“变节”了——它记住了第一次见到的参数模样，却忘了后面的人早已换了一副面孔。
