各位好，我是路远。搞了十五年数据库，我最怕听到的话就是"这个很简单"。

周一早上九点，刚在工位坐下，值班的兄弟转过来一条告警：对账任务超时。这条SQL我熟，从系统上线一路跑到现在，三年了，平时两秒出结果。那天早上，它跑了四十分钟还没出来，应用那头连着断了几次。

我先扫了一眼监控，CPU不高，IO不忙，库闲得很。一条SQL自己慢慢往上爬，库却闲着，这种事儿最不好办，因为它不像故障，更像见鬼。

## 先排除的，是那些"常规嫌疑"

遇到SQL慢，第一反应无非几个：锁、资源、数据量。我按老顺序过了一遍。锁没有，v$lock里干干净净，没人在等谁。资源也不缺，库的负载很低。数据量倒是涨了，这台库每年翻一倍，但要是说数据量能把一条索引查询拖到四十分钟，也不至于。

排到这，我心里其实有了个方向。它平时快、突然慢、库还不忙，这三条凑一起，八成是执行计划变了。同一条SQL，数据库给它算过两套走法，一套快、一套慢，某天早上开始它走了那套慢的。数据这边挑不出毛病，问题出在那个"选择"上。

## 第一件事：把这条SQL的"档案"调出来

Oracle里每条SQL都有身份证，叫SQL_ID。同一条SQL文本，SQL_ID就一个，但它的执行计划可以有好几套，每一套算一个"子游标"，child cursor。我要做的，就是把这条SQL所有子游标全拎出来看：

```sql
SELECT sql_id, child_number, plan_hash_value,
       executions,
       ROUND(elapsed_time/1000/executions) AS avg_ms,
       ROUND(buffer_gets/executions)      AS avg_gets
FROM v$sql
WHERE sql_id = '8gx7m2kq3p1vz';
```

结果一出来，问题就摆在脸上了。同一个SQL_ID底下，两个子游标，plan_hash_value一个是3141592653，另一个是2718281828，明摆着两套计划。再看执行数据：老计划平均两秒，buffer_gets几千；新计划平均四十多分钟，buffer_gets几千万。那个几千万的逻辑读，就是全表扫的签名。

说实话，这回第一反应我判断错过。我一开始以为是数据涨了、索引坏了，方向都偏了，直到把子游标拉出来，才把注意力从"数据"挪到"计划"上。

## 第二件事：把两套计划摆到一起

找到两个plan_hash_value，下一步是把它们逐行比对。我把两个child cursor的计划都打出来：

```sql
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('8gx7m2kq3p1vz', 0, 'ALLSTATS LAST'));
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('8gx7m2kq3p1vz', 1, 'ALLSTATS LAST'));
```

先看快的那套，child 0：

```
SQL_ID  8gx7m2kq3p1vz, child number 0
-------------------------------------
SELECT settle_date, acct_no, amount FROM t_settle_detail
 WHERE settle_date = :d AND status = 'PENDING'

Plan hash value: 3141592653

------------------------------------------------------------------------------------
| Id | Operation                            | Name            | Rows  | Cost (%CPU) |
------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT                     |                 |       |   412 (100) |
|  1 |  TABLE ACCESS BY INDEX ROWID BATCHED | T_SETTLE_DETAIL |    86 |   412   (0) |
|* 2 |   INDEX RANGE SCAN                   | IDX_SETTLE_DATE |    86 |     4   (0) |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
   2 - access("SETTLE_DATE"=:D)
```

再看慢的那套，child 1：

```
SQL_ID  8gx7m2kq3p1vz, child number 1
-------------------------------------
SELECT settle_date, acct_no, amount FROM t_settle_detail
 WHERE settle_date = :d AND status = 'PENDING'

Plan hash value: 2718281828

---------------------------------------------------------------------------------
| Id | Operation          | Name            | Rows   | Cost (%CPU) | Time        |
---------------------------------------------------------------------------------
|  0 | SELECT STATEMENT   |                 |        |  90M (100) |             |
|* 1 |  TABLE ACCESS FULL | T_SETTLE_DETAIL |  58M   |  90M   (1) |  1:23:41    |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
   1 - filter("STATUS"='PENDING' AND "SETTLE_DATE"=:D)
```

两套计划摆一块，差别就落在 Rows 那一列。快的那套，CBO估这条SQL只返回 86 行，走 INDEX RANGE SCAN，代价 412。慢的那套，CBO估它要返回 5800 万行，那还不如把整张表从头扫一遍，TABLE ACCESS FULL，代价九千万。同一条SQL，CBO的估算从 86 行跳到 5800 万行，计划就跟着翻了。一个去目录里翻那一页，一个把整本书从头翻到尾，四十多分钟和两秒，差就差在这。

关键在"估算"这两个字上。CBO选哪套计划，全看它估算谓词要返回多少行。估得少，走索引；估得多，全表扫反倒划算。所以真正的问题不在计划本身，在于CBO那天早上，对这条SQL的估算为什么会翻这么多倍。

## 追根：是谁动了统计信息

CBO的"估算"，靠的是统计信息。我查了这张表统计信息最后一次收集的时间：

```sql
SELECT table_name, num_rows, last_analyzed, stattype_locked
FROM dba_tab_statistics
WHERE table_name = 'T_SETTLE_DETAIL';
```

last_analyzed 是前一天凌晨两点，正是Oracle自动统计信息任务干活的时间点。而再前一版统计信息，是好几周前的。也就是说，周一凌晨，自动任务重新收集了这张表的统计信息，早上CBO就换了套计划。

这里有个很多人绕不过去的弯。他们觉得统计信息是"越新越准、越准越好"，收集完计划就该更优。事实不是这样。这张表几周前的统计信息是旧的，那时候表还没这么大，CBO以为表小，对 settle_date 的估算踩中了，计划恰好走了索引，快。凌晨统计信息一刷新，CBO终于认清表大了，可它对绑定变量 settle_date 看不到具体值，只能按平均值估，这一"平均"就估歪了，算出全表扫更便宜。统计信息变准了，计划反而变差了。这事儿听着别扭，在Oracle上却一点不稀奇。

CBO算出来的东西，本质是个概率。数据分布一变，或者它采样的样本一变，这个概率就翻个面。

## 还有一条更隐蔽的岔路：绑定变量窥探

上面这个是统计信息刷新触发的计划翻转。还有一条更鬼的岔路，叫绑定变量窥探，bind peeking，得单独拎出来说。

应用写的SQL，一般不把值写死，而是用绑定变量，比如 where settle_date = :d。好处是SQL文本不变，解析一次反复用，省资源。代价是，CBO在第一次硬解析时看不到未来的值是啥，只能"窥探"这一次传进来的值。要是第一次传进来的是个特殊的边界值，CBO照着它生成一套计划，后面的值哪怕完全不一样，也只能复用这一套。一条SQL，被第一次那个值"钉"死了。

这套毛病，11g之后用自适应游标共享（ACS）缓和了不少，它会根据实际执行情况，给一条SQL多备几套计划。但它不是万能药，数据倾斜、直方图缺位的时候，照样翻车。判断自己有没有踩这条道，看一点就够：同一个SQL_ID底下，计划会随着绑定值来回横跳，那就八成是它。

## 要让计划别再乱变，三条路

找到根因，收拾起来就相对清楚了。核心目标只有一个：让这条SQL，稳定走那套快的计划。

第一条，也是最直接的：把好计划钉下来，用SQL Plan Baseline。Oracle的SPM就是干这个的，把现在跑得对的那套计划，从游标缓存或者AWR里加载成计划基线，以后CBO再想换，得先过基线这一关：

```sql
DECLARE
  l_cnt PLS_INTEGER;
BEGIN
  l_cnt := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(
             sql_id          => '8gx7m2kq3p1vz',
             plan_hash_value => 3141592653);
END;
/
```

这条钉的是"这一套计划"。往后数据再变，只要这套计划还作数，CBO就不会自己乱换。

第二条，治本一点：管住统计信息。这张表的数据分布我看了，settle_date 高度倾斜，月初月尾差着量级。这种列，得给它配上直方图，别让CBO拿"平均值"去估。再稳一点的做法，是把关键表的统计信息收集策略控死，该锁的锁起来，别让半夜的自动任务在你睡着的时候动它。

第三条，改写或加HINT，逼CBO走对的路。这招见效快，但最不该随手用，后面避坑清单里我细说。

## 换个库，这套机制认不认

收拾完这单，我顺手把几家的执行计划稳定性机制摆一块看了看。国产库里跟Oracle兼容的居多，这套"统计信息＋游标＋计划基线"的思路基本都搬过来了：

| 维度     | Oracle            | MySQL          | 国产库（兼容Oracle）  |
| ------ | ----------------- | -------------- | ------------- |
| 计划缓存   | 共享池游标（child cursor） | 无，每会话预编译       | 类Oracle，多子游标  |
| 统计信息   | DBMS_STATS，自动任务    | ANALYZE TABLE  | 多为DBMS_STATS兼容 |
| 计划基线   | SQL Plan Baseline（SPM） | 无原生           | 部分提供，成熟度不一    |
| 绑定变量窥探 | 有，ACS缓解           | 有，8.0起改善       | 视实现而定         |
| 直方图    | 有                 | 8.0起支持         | 多支持           |

这张表里有两点特别要留意。一是计划基线这类"稳计划"的手段，Oracle上很成熟，国产库各家还在补，迁移前务必确认目标库有没有对应的能力，别把Oracle上的一条保命招默认搬过去。二是统计信息的自动收集，国产库大多也有，但默认策略、收集窗口跟Oracle不一定一样，别拿Oracle的经验直接套。

会Oracle这套排查思路，去国产库上大体能上手，但"能上手"和"能兜底"是两码事，上线前把目标库这几种机制翻一遍手册。

## 避坑清单

下面三条，是我经这单之后给自己加的规矩，各位对着自己的库看看。

**第一，SQL突然变慢、库却不忙，先别去查锁和资源，直接看执行计划。** 这种"库很闲、SQL很慢"的组合，八成是计划翻了，把v$sql里这条SQL的子游标拉出来，一眼见分晓。

**第二，统计信息不是越新越好，关键表要管住。** 别迷信"自动收集"，对数据倾斜的表，配好直方图，必要时把统计信息锁死，让收集这件事可控，而不是撞运气。

**第三，也是我这次才彻底想明白的：HINT要慎用，加了不好撤。** 有一年我也遇到计划翻转，图省事给SQL硬加了个走索引的HINT，当时确实好了。半年后数据分布变了，那条HINT逼着CBO一直走索引，反倒把一条本该全表扫的SQL拖垮了。HINT是把"这一套计划"钉死，可数据是会变的，钉得太死，早晚钉到自己脚上。能用基线、能改统计信息解决的，别急着上手写HINT。

## 写在最后

回头看这单，现场处理其实就几下：拉出子游标、比对两套计划、钉住好计划。真正花时间的，是想明白一个反直觉的道理：执行计划变准，不等于变好。

Oracle这套CBO算的是概率，跟"真理"不沾边。它估得准不准，受统计信息、绑定值、直方图一圈东西牵着。所以计划能不能稳，跟收集得勤不勤关系不大，跟管不管得住关系很大。哪张表该锁统计信息，哪条SQL该挂基线，心里得有本账。

你们那边有没有遇到过，一条跑了三年的SQL，某天早上突然就翻脸了？最后是怎么把它摁回去的，评论区聊聊，互相避坑。

我是路远。数据库这事儿，生产环境说了算。


周一早上九点，刚在工位坐下，值班的兄弟转过来一条告警：对账任务超时。这条SQL我熟，从系统上线一路跑到现在，三年了，平时两秒出结果。那天早上，它跑了四十分钟还没出来，应用那头连着断了几次。

Oracle执行计划突变避坑：2秒变40分钟，三步固定计划

周一早上，一条跑了三年的对账SQL从两秒变成四十分钟，库却一点不忙。这次不聊加索引，往下拆Oracle执行计划为什么会突变：统计信息刷新触发的计划翻转、绑定变量窥探这条更隐蔽的岔路、用SQL Plan Baseline把好计划钉住，附多库机制对比与三条避坑。

数据库

运维

SQL性能骤降排查指南：Oracle执行计划翻转的根因与修复方案。本文通过真实案例，分析统计信息刷新如何导致CBO误判、绑定变量窥探的隐蔽影响，提供SQL Plan Baseline、直方图配置及HINT使用避坑清单，助你稳定SQL执行计划，避免全表扫描陷阱。

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Oracle执行计划突变避坑：2秒变40分钟，三步固定计划-腾讯云开发者社区-腾讯云

Oracle执行计划突变避坑：2秒变40分钟，三步固定计划

Oracle执行计划突变避坑：2秒变40分钟，三步固定计划

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐