执行计划一夜之间变了？别查代码了，是统计信息在“说谎“-平芜编程栈

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

有个经典的"凌晨惊魂"场景：某条核心SQL跑了半年都没问题，每天几十万次执行，响应时间稳定在5毫秒以内。某天凌晨三点，监控告警疯狂弹窗——这条SQL突然飙到5秒，CPU打满，整个系统雪崩。

DBA赶到现场，第一反应是看代码有没有人改。没有。看索引有没有人删。没有。看数据量有没有暴涨。也没有。

最后查下来，原因让人无语：统计信息过期了。数据库优化器拿着一份"过时的情报"，给这条SQL选了一条错误的执行计划。

今天把执行计划突变的底层原理、排查手段和预防机制，一次讲清楚。

一、先搞懂几个概念

执行计划（Execution Plan）：数据库执行一条SQL的具体步骤。先走哪个索引、先JOIN哪张表、用什么JOIN方式（Nested Loop、Hash Join、Merge Join），这些决策组合起来就是执行计划。

优化器（Optimizer）：数据库里的"决策引擎"，负责为每条SQL选择最优的执行计划。它不跑SQL，只"猜"哪种执行方式最快。

统计信息（Statistics）：优化器做决策的依据。包括表的总行数、每列的数据分布（最大值、最小值、NULL占比、直方图）、索引的选择性（不同值的数量）等。本质上就是优化器眼中的"数据库快照"。

基数估计（Cardinality Estimation）：优化器预估每一步会返回多少行数据。预估准了，执行计划就优；预估偏了，就可能选错索引、选错JOIN顺序。

CBO（Cost-Based Optimizer）：基于成本的优化器。优化器根据统计信息计算每种执行计划的"成本"（CPU消耗、IO次数、内存占用），选成本最低的那个。

理解了这些概念，就能回答一个核心问题：为什么执行计划会突然变？

二、执行计划为什么会"背叛"你

统计信息过期：优化器拿到的是"过期情报"

这是最常见的原因。统计信息不是实时更新的，大多数数据库是定期收集或手动触发。

假设你有一张订单表，平时100万行，统计信息也是按这个量级收集的。某天大促，数据量涨到500万，但统计信息还没更新。优化器依然认为表里只有100万行——于是选择了全表扫描（因为它觉得100万行全表扫比走索引快）。实际上500万行全表扫描直接卡死。

统计信息 ≠ 实时数据，它是一份"延迟的快照"。

数据倾斜：平均值骗了优化器

即使统计信息是新的，也可能因为数据分布不均匀而误导优化器。

比如一个订单表的status列，99%的数据是COMPLETED，1%是PENDING。如果统计信息只记录了平均分布（没有收集直方图），优化器会认为每个状态的占比差不多。当你查询status = 'COMPLETED'时，优化器预估返回1000行（总行数10万的1/100），实际返回99000行——走索引反而比全表扫慢几十倍。

索引变化：新增索引不一定是好事

开发同学看到慢SQL，第一反应是加索引。加完索引后统计信息更新，优化器重新评估所有可用索引，可能选出一个更差的执行计划。

加索引 ≠ SQL变快，它只是给优化器多了一个选择，而这个选择可能是错的。

参数变更：看似无关的配置调整

optimizer_mode从ALL_ROWS改为FIRST_ROWS
optimizer_features_enable版本升级后行为变化
statistics_level从TYPICAL改为BASIC（停止收集部分统计信息）

这些参数调整不会立刻生效，但下一次硬解析时，优化器的决策逻辑可能完全改变。

三、执行计划突变的排查步骤

第一步：确认是不是执行计划变了

-- Oracle SELECT * FROM v$sql_plan WHERE sql_id = 'your_sql_id'; -- MySQL (8.0+) EXPLAIN FORMAT=TREE SELECT ...; -- PostgreSQL EXPLAIN (ANALYZE, BUFFERS) SELECT ...; -- 对比历史执行计划 -- Oracle: DBMS_XPLAN.DISPLAY_AWR('your_sql_id')

重点对比：访问路径（全表扫 vs 索引扫描）、JOIN顺序、JOIN方式、预估行数 vs 实际行数。

第二步：检查统计信息是否过期

-- Oracle：查看表的统计信息收集时间 SELECT table_name, last_analyzed, num_rows, blocks FROM user_tables WHERE table_name = 'YOUR_TABLE'; -- MySQL：查看InnoDB表统计信息 SHOW TABLE STATUS LIKE 'your_table'; -- PostgreSQL：查看统计信息 SELECT last_analyze, last_autoanalyze, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'your_table';

如果last_analyzed是几天甚至几周前，而这段时间数据变化超过10%，基本可以判定统计信息过期。

第三步：对比预估行数和实际行数

这是判断优化器是否"误判"的关键指标。

-- 执行SQL时开启实际执行统计 -- Oracle: EXPLAIN PLAN FOR ... 然后 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); -- MySQL: EXPLAIN ANALYZE SELECT ...; -- PostgreSQL: EXPLAIN ANALYZE SELECT ...;

如果某一步的预估行数（estimated rows）和实际行数（actual rows）相差10倍以上，说明基数估计严重失真，执行计划很可能选错了。

第四步：检查是否有绑定变量窥探问题

绑定变量第一次执行时，优化器会"窥探"变量值来生成执行计划。后续执行直接复用这个计划，即使变量值的数据分布差异很大。

比如第一次传的是status = 'PENDING'（只有100行），优化器选了索引扫描。后面传的是status = 'COMPLETED'（99000行），还是走索引——但全表扫描反而更快。

四、预防执行计划突变的4种手段

手段一：合理设置统计信息收集策略

不要完全依赖自动收集，根据业务特点定制：

策略	适用场景	收集频率
自动收集 + 默认阈值	数据变化平稳的普通表	系统自动触发
手动定时收集	数据批量导入/删除的表	每天凌晨或批量操作后
锁定统计信息	历史归档表（数据不变化）	收集一次后锁定
收集直方图	数据分布严重倾斜的列	按需收集

-- Oracle: 手动收集统计信息（含直方图） EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'TABLE_NAME', method_opt => 'FOR COLUMNS SIZE AUTO skewed_column'); -- MySQL: 手动分析表 ANALYZE TABLE your_table; -- PostgreSQL: 手动分析 ANALYZE your_table;

手段二：使用执行计划基线（Plan Baseline）

Oracle提供了SQL Plan Management（SPM），可以把"好的执行计划"锁定下来，即使统计信息变化也不让优化器切换到更差的计划。

-- Oracle: 创建执行计划基线 DECLARE l_plans_loaded PLS_INTEGER; BEGIN l_plans_loaded := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE( sql_id => 'your_sql_id'); END;

金仓数据库也提供了类似的执行计划管理能力。通过DBMS_SPM兼容包，可以将经过验证的优秀执行计划固定下来，避免因统计信息变化导致的性能波动。同时支持执行计划演化（evolve），在确认新计划更优后才自动切换。

手段三：SQL Profile / Outline

SQL Profile是优化器的"纠正器"。当发现某条SQL的执行计划不理想时，可以创建一个SQL Profile，告诉优化器"这条SQL按这个方式执行"。

-- Oracle: 使用SQL TUNING ADVISOR DECLARE l_tuning_task VARCHAR2(30); BEGIN l_tuning_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_id => 'your_sql_id'); DBMS_SQLTUNE.EXECUTE_TUNING_TASK(l_tuning_task); DBMS_SQLTUNE.ACCEPT_SQL_PROFILE(task_name => l_tuning_task); END;

手段四：监控统计信息变化

建立监控机制，在统计信息过期前主动预警：

-- 找出统计信息超过7天未更新的表 SELECT table_name, last_analyzed, ROUND((SYSDATE - last_analyzed), 1) as days_since_analyze FROM user_tables WHERE last_analyzed < SYSDATE - 7 ORDER BY last_analyzed;

建议在监控系统中加入以下告警项：