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

前阵子开发同事抱了台笔记本过来，路哥，帮我看看这条跑批SQL。我先拉了执行计划，索引路径，没问题。又看了眼统计信息，发现这表是分区交换加载的，自动统计任务基本覆盖不到，迟早熬到过期。我提醒开发，把统计信息收集写进ETL，再把执行计划固定下来，不然计划一变，这条SQL就难说。对方说行，回头落实，实际没动。结果上周凌晨，统计信息果然过期，这条"很简单"的SQL把核心交易库CPU顶到100%，58个会话全部卡死。今天把这单完整复盘一遍，各位下次遇到，能少走点弯路。

## 第一现场：会话和等待事件

登录上去，我没先看CPU，先看会话在等什么。CPU高只是现象，得搞清楚CPU被谁吃了、会话卡在哪。我查了最近30分钟的活动会话：

```sql
SELECT sql_id, COUNT(*) sessions,
       ROUND(SUM(CPU_USED)/1e6, 1) cpu_sec
FROM v$active_session_history
WHERE sample_time > SYSDATE - 30/1440
GROUP BY sql_id
ORDER BY cpu_sec DESC
FETCH FIRST 5 ROWS ONLY;
```

结果很干净，就一个SQL_ID占了七成CPU：

```
SQL_ID          SESSIONS    CPU_SEC
--------------- --------    -------
7qx8k2f3mz1ab         58      182.4
```

58个会话同时跑这一条SQL。我又翻了ASH的等待事件分布，除了CPU，还有不少db file scattered read，这是全表扫描的多块读，基本坐实了扫描量异常。顺着SQL_ID把文本拉出来：

```sql
SELECT u.city_id,
       COUNT(*),
       SUM(o.amount)
  FROM order_master o
  JOIN user_profile u ON u.user_id = o.user_id
 WHERE o.created_at >= TRUNC(SYSDATE) - 1
   AND o.status = 'PAID'
 GROUP BY u.city_id;
```

日终报表任务，凌晨低峰跑，平时几分钟完事。今天被58个会话同时执行，为什么跑批会开58个并发，根因里一起说。

## 执行计划：优化器挑了条最贵的路

我把AWR里这个SQL的计划调出来。正常情况下走索引、嵌套循环：

```sql
SELECT * FROM TABLE(
  DBMS_XPLAN.DISPLAY_AWR('7qx8k2f3mz1ab', NULL, NULL, 'ALL'));
```

```
---------------------------------------------------------------------------
| Id | Operation                  | Name               | Rows | Cost |
---------------------------------------------------------------------------
|  0 | SELECT STATEMENT           |                    |   50 |  820 |
|  1 |  SORT GROUP BY NOSORT      |                    |   50 |  820 |
|  2 |   NESTED LOOPS             |                    |   50 |  818 |
|  3 |    TABLE ACCESS BY INDEX ROWID | ORDER_MASTER  |   50 |   12 |
|  4 |     INDEX RANGE SCAN       | IDX_ORDER_STATUS   |   50 |    4 |
|  5 |    INDEX UNIQUE SCAN       | PK_USER            |    1 |    1 |
---------------------------------------------------------------------------
```

实际走的却是全表扫描加Hash Join：

```
---------------------------------------------------------------------------
| Id | Operation            | Name          | Rows  | Cost | Time        |
---------------------------------------------------------------------------
|  0 | SELECT STATEMENT     |               |    50 | 98234 | 00:14:32   |
|  1 |  HASH GROUP BY       |               |    50 | 98234 | 00:14:32   |
|  2 |   HASH JOIN          |               |    50 | 98230 | 00:14:32   |
|  3 |    TABLE ACCESS FULL | ORDER_MASTER  | 5000K | 91220 | 00:13:30   |
|  4 |    TABLE ACCESS FULL | USER_PROFILE  | 1000K | 7000  | 00:00:52   |
---------------------------------------------------------------------------
```

两张千万级大表全扫，再来个Hash Join，优化器估了14分钟，实际CPU直接顶满。注意Rows这列，ORDER_MASTER估了5000K，这个数是估的。基数估算用列的选择性乘表行数，谓词是status='PAID'，统计信息里这张表才50万行，估出的返回行数自然小，全表扫描代价就被低估了。status列要是有数据倾斜又缺直方图，偏差能到几个数量级。我上库一数，实际5287万行，和统计信息差了100倍。

## 根因：统计信息过期，分区交换是帮凶

查两张表的统计信息：

```sql
SELECT table_name, num_rows, last_analyzed
FROM dba_tables
WHERE table_name IN ('ORDER_MASTER', 'USER_PROFILE');
```

```
TABLE_NAME    NUM_ROWS    LAST_ANALYZED
-----------   --------    -------------
ORDER_MASTER     502,384  2026-06-20
USER_PROFILE    1,032,917  2026-06-20
```

ORDER_MASTER统计信息里50万行，实际5287万行，差了一百倍。统计信息停在6月20号，两个月没更新，根子出在加载流程。这张表按月分区，每天ETL用分区交换批量导入。分区交换在数据字典层面瞬间完成，不产生DML，所以不会自动触发统计信息采集。Oracle的自动统计任务有STALE_PERCENT阈值，默认表变化10%才标记过期，分区交换绕过这个机制，统计信息永远不觉得自己该更新。自动任务窗口是晚上10点到凌晨2点，这张表凌晨3点才加载，完美错过，人工也没补。这个坑我不陌生，五年前导了2亿行忘了收统计信息，第二天核心报表全挂。

## 止血：先kill会话，再收统计信息

确认根因，我没急着收统计信息，先把58个会话按住。跑批可以重跑，CPU不释放，其他业务跟着陪葬。kill之前我查了v$transaction，确认没有未提交的关键事务，undo使用量也在安全范围，才批量KILL：

```sql
ALTER SYSTEM KILL SESSION '1234,56789' IMMEDIATE;
```

会话清掉CPU回落，我紧接着收集统计信息。分区表记得用INCREMENTAL，全量收集太慢：

```sql
EXEC DBMS_STATS.GATHER_TABLE_STATS(
  USER, 'ORDER_MASTER', CASCADE => TRUE, DEGREE => 8,
  INCREMENTAL => TRUE);
EXEC DBMS_STATS.GATHER_TABLE_STATS(
  USER, 'USER_PROFILE', CASCADE => TRUE, DEGREE => 8);
```

收集完执行计划切回索引路径，代价从98234掉回820。凌晨3:55跑批重跑，4分钟完事，从告警到恢复35分钟。顺序不能反，5287万行收统计信息跑了6分钟，这6分钟CPU有波动，先kill会话让出CPU再收，不然收集过程可能把库再拖垮一次。

## 复盘：并发放大效应

问题解决了，但"为什么58个会话同时跑一条跑批SQL"还没解开。查了任务调度，跑批配置的是并行执行，调度平台按city_id拆成60个子任务并发下发。平时SQL快，60个并发没事；今天执行计划翻车，60个并发全表扫描，等于60把刀一起捅库。58个会话共享buffer cache，全表扫描把热点数据全冲掉，其他业务的命中率跟着掉，这是连锁反应。跑批上线只测了功能，没看执行计划，也没做并发压测，这是流程漏洞，不是技术问题。

## 避坑清单

复盘完，我在这套系统上立了四条规矩，各位可以对照自己环境看看。

统计信息收集必须纳入ETL流程，批量加载完就收，别指望自动任务。分区交换这种加载方式尤其坑，它在数据字典层面瞬间完成，不触发统计信息更新，数据量大就用INCREMENTAL增量统计。

关键跑批SQL固定执行计划。**Oracle环境**用SQL Plan Baseline，先从cursor cache捞计划再load进SPM：

```sql
DECLARE
  l_plans NUMBER;
BEGIN
  l_plans := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(
    sql_id => '7qx8k2f3mz1ab');
END;
```

如果是MySQL环境，没有SPM，退而求其次，跑批SQL显式写index hint，丑是丑点，稳。不过要注意，索引名变更后hint会失效，变更索引时要同步更新SQL。固定计划之前先把SQL本身改对，我见过有人把全表扫描的烂计划固化了两周，所有人都以为没问题。

凌晨低峰期也要盯监控，跑批执行时间超过基线两倍就告警，CPU打满往往先在半夜冒头，别等业务投诉。

应急时先kill会话让出CPU，再收统计信息，顺序反了就是二次事故。

说句实在话。数据库性能事故，多数不是数据库不行，是它被蒙着眼睛干活。统计信息就是优化器的眼睛，眼睛瞎了，再好的优化器也会挑最烂的路。这次35分钟恢复，靠的不是多高明的操作，是平时把监控和流程补齐了。技术问题都好解，流程漏洞才难补。

各位还遇到过哪些把库打垮的SQL？评论区聊聊，互相避坑。

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

前阵子开发同事抱了台笔记本过来，路哥，帮我看看这条跑批SQL。我先拉了执行计划，索引路径，没问题。又看了眼统计信息，发现这表是分区交换加载的，自动统计任务基本覆盖不到，迟早熬到过期。我提醒开发，把统计信息收集写进ETL，再把执行计划固定下来，不然计划一变，这条SQL就难说。对方说行，回头落实，实际没动。结果上周凌晨，统计信息果然过期，这条"很简单"的SQL把核心交易库CPU顶到100%，58个会话全部卡死。今天把这单完整复盘一遍，各位下次遇到，能少走点弯路。

SQL性能事故排查实战：统计信息过期如何让优化器选错执行计划

一条"很简单"的跑批SQL把核心交易库CPU顶到100%、58个会话卡死。从定位SQL、对比执行计划到揪出统计信息过期与分区交换的坑，完整复盘35分钟应急处置并给出四条避坑清单。

数据库

后端

职业发展

数据库跑批SQL因统计信息过期导致核心库CPU打满、58个会话卡死，从ASH分析、执行计划对比到根因定位，复盘分区交换加载绕过统计信息采集的陷阱，给出ETL中嵌入统计收集、SQL Plan Baseline固定计划、监控基线告警等避坑方案，35分钟恢复实战经验。

代码解释

MySQL

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

SQL性能事故排查实战：统计信息过期如何让优化器选错执行计划-腾讯云开发者社区-腾讯云

SQL性能事故排查实战：统计信息过期如何让优化器选错执行计划

SQL性能事故排查实战：统计信息过期如何让优化器选错执行计划

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐