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

上周一个做国产化迁移的兄弟找我，项目刚迁完，数据、功能都通了，就一条核心查询慢：在Oracle上1.2秒，换到新库变成3.8秒。他第一反应是"这库是不是不行"。我说先别急着下结论，同一份数据、同一条SQL，慢下来十有八九不是库本身的问题，是迁的时候漏了东西。今天把这单完整复盘一遍，各位在做迁移的，大概率也会撞到。

## 第一现场：先确认不是偶发

我没急着看计划。做迁移排查，第一步永远是排除偶发。我让他把这条SQL在两个库上各跑五遍，取稳定值；再避开跑批时段，清空缓存跑一次冷数据。结果很稳，Oracle在1.2到1.4秒之间晃，新库是3.6到3.9秒。

不是缓存，不是并发，不是网络。就是执行计划本身慢。排除法做完，方向就清楚了，问题出在优化器挑的那条路子上。

## 两套执行计划，并排一比

先在Oracle这边把计划拉出来：

```sql
SELECT * FROM TABLE(
  DBMS_XPLAN.DISPLAY_CURSOR('7bq4n1k9pst2c', NULL, 'ALLSTATS LAST'));
```

走的是索引范围扫描加嵌套循环，代价三百出头：

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

再看新库这边，用它自己的EXPLAIN把真实执行情况打出来：

```sql
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
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 >= CURRENT_DATE - 1
   AND o.status = 'PAID'
 GROUP BY u.city_id;
```

命令语法各库不一样，这一步省不得，看计划永远比猜计划快。结果出来，全表扫描加Hash Join：

```
| Id | Operation        | Name           | Rows  | Cost  | Time    |
|----|------------------|----------------|-------|-------|---------|
|  0 | SELECT STATEMENT |                |       | 91240 | 00:03.8 |
|  1 |  HASH GROUP BY   |                |    50 | 91240 | 00:03.8 |
|  2 |   HASH JOIN      |                |    50 | 91236 | 00:03.8 |
|  3 |    SEQ SCAN      | ORDER_MASTER   | 5000K | 84100 | 00:03.2 |
|  4 |    SEQ SCAN      | USER_PROFILE   | 1000K |  7000 | 00:00.5 |
```

两张千万级的大表全扫，再挂一个Hash Join。注意Rows这一列，ORDER_MASTER估了5000K行。这个数是估的，不是真的，记住这一点，根因就在这儿。

## 盯着差异点往下挖

同一个查询、同样的WHERE条件，两边的执行计划走了两条路。差别就一个地方，优化器对返回行数的估算。

这条SQL的谓词是status等值加时间范围。Oracle的统计信息里，索引列选择性还行，估出返回50行，走索引代价小；新库这边统计信息缺位，估出5000K行，一算账，全表扫加Hash Join反而更便宜，就选了它。

优化器的选择没有对错。它只是在用你给它的信息算账。你给它错的数，它就算出错的账，选错的路。这跟库是哪家的没关系，换成谁，缺了统计信息都一样。

## 根因：对象迁了，统计信息没迁

我查了两边的统计信息。Oracle这边：

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

```
TABLE_NAME      NUM_ROWS    LAST_ANALYZED
-------------   ---------   -------------
ORDER_MASTER       528,164   2026-09-10
USER_PROFILE     1,032,917   2026-09-10
```

再看新库这边的统计信息，num_rows基本是空的。不是新库不收集，是数据迁完之后没人触发过收集，系统视图里自然一片空白。

根子找到了。表结构、索引、约束带过去了，数据也灌进去了，唯独统计信息没跟着走。迁移项目里的数据同步，通常交给专业的同步工具去做，像金仓的异构数据同步软件 KFS（Kingbase FlySync）这类工具，全量加增量、实时同步、双跑比对，本来就是它的强项，数据搬得又快又准。但统计信息是另一码事，它不是数据对象，不带DDL，得迁完之后在新库上单独收。新库上这条SQL第一次跑，优化器手里没有任何可用的行数信息，只能拍脑袋估，估出来的基数和真实值差了好几个数量级。

Oracle那张表跑批后有套自动收集任务兜着，优化器的眼睛天天是亮的；到了新库，这套任务要重新配置、数据要重新收集，没人做，眼睛就先闭着。说到底，这不是哪个库的毛病，是搬家的活儿没干完。

还有一层更隐蔽的，直方图。status这种列，值就那么几个，但PAID可能占了九成，其他状态加起来才一成，典型的数据倾斜。统计信息里要是没带直方图，优化器认不出倾斜，就按平均值估，把占九成的PAID当成均匀分布里的一小撮，行数自然估飞。Oracle默认会收直方图，新库这边也一样，收统计的时候把重点列带上直方图，优化器才认得出倾斜。迁移时这份信息没补上，这一条就成了漏网之鱼。

## 止血：收统计信息，再把计划掰回来

确认根因，我没急着改SQL。先在新库上收统计信息，重点列带上直方图，先让优化器把数据摸清楚，再让它干活。收完让它重新解析这条SQL，执行计划切回索引路径，代价从九万多掉到三百出头，和Oracle基本一个量级。再实测一遍，1.3秒，拉平了。

光收完还不够。我把这条SQL固定下来，Oracle这边用SQL Plan Baseline锁住计划；新库那边也有自己的计划管理手段，按新库的机制把这条SQL的计划固定住，别让它下次又变脸。迁移项目的性能，得养，不能指望一次收统计就一劳永逸。

## 复盘：迁移丢掉的隐形资产

说白了，迁移这件事，迁的是数据，丢的常常是"经验"。

搬数据这件事，KFS 这类同步工具已经做得很成熟，全量加增量、双向校验都替你备好了。可执行计划、统计信息、绑定变量、参数配置，这些东西在Oracle里养了好几年，是看不见的资产，得靠人在新库上一项项补回来，验收清单也常常漏掉它们。迁过去的是一个能跑起来的空壳，跑得好不好，得在新库上重新养一遍。

运维上的习惯也得跟着改。Oracle那套自动统计任务，大家习惯了放着不管；到了新库，收集策略、窗口、频率、并发这些参数，得按新库的机制重新配一遍，配好了它照样能自动兜底。这一步偷懒，代价往往就是上线后才发现的慢。

## 避坑清单

复盘完，我在迁移流程里立了几条规矩，各位可以对着自己项目看看。

迁移后第一件事是收集统计信息，再去谈性能验收，别等业务投诉才补。数据量大就分区收、增量收，别一把梭全量，收集过程自己就能把库压垮一次。

统计信息里该带直方图的列一定要带上，尤其是像status这种取值少、分布又悬殊的列。不建，优化器就按平均值估，行数能估飞几个数量级，这是最容易被忽略的一条。

验收清单里加一项：核心SQL迁移前后的执行计划对比。数据一致性有 KFS 的比对服务兜着，DBA 的精力别全砸在那上头，功能通了不算通，计划对了才算通。

说句实在话，我这次差点跳步。我的第一反应是给SQL加个hint，把计划按到索引上，两分钟就能完事。我还是忍住了，先去查统计信息，才确认根子在那里。hint能压住一个烂计划，压不住一份烂统计，下次计划一变，hint一失效，又是一个样。

## 写在最后

把这次的经验收拢成一句话：迁移不是搬数据，是把一套运行习惯在新地方重新养一遍。

说到底，这跟库选哪家没关系。Oracle也好，国产库也好，优化器只认你给的统计信息。信息给对了，它挑的路就差不了。迁完之后多花半天收统计、对执行计划，比上线以后半夜爬起来救火，划算太多。

各位迁移的时候，踩过哪些性能上的坑？评论区聊聊，互相避坑。

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


上周一个做国产化迁移的兄弟找我，项目刚迁完，数据、功能都通了，就一条核心查询慢：在Oracle上1.2秒，换到新库变成3.8秒。他第一反应是"这库是不是不行"。我说先别急着下结论，同一份数据、同一条SQL，慢下来十有八九不是库本身的问题，是迁的时候漏了东西。今天把这单完整复盘一遍，各位在做迁移的，大概率也会撞到。

核心查询迁移后性能下降：执行计划差异的定位与统计信息修复复盘

核心查询迁移后，同一条SQL、同一份数据，从1.2秒变成3.8秒。从两套执行计划对比入手，揪出统计信息没跟着迁、基数估算偏差几个数量级的根因，讲透迁移里最容易被漏掉的隐形资产，附迁移验收清单与四条避坑。这不是库行不行，是搬家的活儿没干完。

数据库

运维

架构设计

数据库迁移后查询性能骤降？核心原因往往不是数据库本身，而是统计信息缺失。本文复盘一个Oracle迁移案例，展示如何通过对比执行计划、重建统计信息与直方图，将查询时间从3.8秒恢复至1.3秒。迁移不止搬数据，更要迁移运行习惯，建议收藏避坑清单。

数据一致性

数据同步

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

核心查询迁移后性能下降：执行计划差异的定位与统计信息修复复盘-腾讯云开发者社区-腾讯云

核心查询迁移后性能下降：执行计划差异的定位与统计信息修复复盘

核心查询迁移后性能下降：执行计划差异的定位与统计信息修复复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐