Oracle 10046 Trace 硬核指南:SQL 慢在哪,从底层拉出来

在生产系统里,SQL 变慢从来不是"突然发生的"。

它只是到了一个节点,你终于看见它慢了。

大多数 DBA 真正的痛点,不在于不会看执行计划,而在于:

执行计划没问题,SQL 却就是慢。

Explain plan 很完美,索引齐全,逻辑正常,可用户体验就是不对。这种时候再反复 explain 只是在"安慰自己",它无法告诉你数据库当下到底在干什么。

10046 的价值就在这里,它给你的不是"理论路径",而是执行过程的完整现场记录。

10046 到底解决什么问题?

很多人把 10046 当成"高级版 explain plan",这是误解。

Explain plan 解决的是:

优化器打算怎么跑。

10046 解决的是:

数据库真正正在干什么。

它记录的不仅是路径,还有:

• 每一次物理读和逻辑读

• 每一个等待事件

• 每一次 parse / execute / fetch 的耗时

• 每一次绑定值的真实输入

• 执行过程是否被打断、等待、阻塞

这意味着什么?

意味着当你面对"偶发慢 SQL""线上抖动""某些用户卡顿",你不再靠猜。

你能看到:

• 这次慢是因为走了全表扫描?

• 还是磁盘响应慢?

• 是锁没放?

• 是 PGA 不够?

• 还是执行计划发生了翻转?

这些在 trace 里是实打实写出来的,不是推断。

一次标准的开启流程

执行顺序固定,不要省略:

复制代码
alter session set timed_statistics = true;
alter session set statistics_level = all;
alter session set max_dump_file_size = unlimited;
alter session set events '10046 trace name context forever, level 12';

你执行 SQL。

跑完立刻关闭:

复制代码
alter session set events '10046 trace name context off';

为什么必须 level 12?

因为:

• 不要只看 SQL

• 不要只看执行时间

• DBA 只需要最完整版本

tkprof:你真正该看的入口

原始 .trc 文件可读性很差,不建议直接翻。

直接格式化:

复制代码
tkprof xxx.trc output.txt sys=no sort=exeela,fchela

Execution Plan:你唯一该信的那份

进入 output 文件,直接搜:

Execution Plan

你看到的不是 explain plan,不是 display_cursor。

而是:

SQL 实际走过的执行路径。

这是重要到值得强调的一点:

很多 SQL 的性能问题,本质就发生在------

"你以为它走 A,但它其实走了 B"。

最常见的翻车现场包括:

• 预期走索引,实际全表

• 希望 Nested Loop,结果 Hash Join

• 明明有复合索引,却拆开扫描

• 表数据量暴增但统计信息没更新

这些,你在 explain 阶段看不出来,

10046 会让你当场看到。

慢从哪来:不是只看 elapsed

你必须学会看这一段:

call count cpu elapsed disk query current

Parse

Execute

Fetch

这是诊断 SQL 的命根子。

经验判断:

• elapsed 远大于 CPU,说明不在算,在等

• disk/query 畸高,说明 IO 在拖后腿

• fetch 次数很少但时间很长,大概率锁或远程访问

• execute 阶段慢,意味着执行路径效率本身有问题

• parse 时间反复高,说明 SQL 没被复用

这一步的价值在于:

你不再纠结 SQL 写法,

而是明确瓶颈是算力问题、IO问题、锁问题、设计问题。

这是 DBA 和"调 SQL 工程师"的分水岭。

等待事件:数据库不会"无缘无故慢"

在 tkprof 中搜:

WAIT

你会看到这条 SQL 在执行期间:

到底:

• 在等 IO

• 在等 latch

• 在等 lock

• 在等 commit

• 在等 buffer

数据库的世界很简单:

不是在干活,

就是在等别人干完。

10046 唯一的意义就在于:

你知道它是在"干",还是在"等"。

Bind 值:谁在坑你,一目了然

Level 12 会把绑定变量打出来。

你真正能看到:

Bind#0: value=...

这意味着:

• 你能发现数据倾斜

• 能验证是否选错执行路径

• 能判断参数化是否合理

• 能确认是输入问题还是 SQL 设计问题

这一步,是 explain 做不到的。

什么时候才值得用 10046?

如果你满足这些情况之一:

• SQL 偶发慢

• 下载跑飞

• 锁查不清

• 同 SQL 不同表现

• 执行计划频繁抖动

• "有时快有时慢"

那你就不该再犹豫。

DBA 的底牌

10046 不是常规工具,它是:

DBA 手里的取证设备。

当别人说"数据库慢",

你没有感觉,没有猜测,只有图和证据。

这才是 DBA 的底气。

相关推荐
_ziva_19 小时前
MAC-SQL 多智能体协作框架解析
数据库·oracle
最贪吃的虎19 小时前
Redis其实并不是线程安全的
java·开发语言·数据库·redis·后端·缓存·lua
代码不停19 小时前
MySQL事务
android·数据库·mysql
山峰哥19 小时前
数据库工程与SQL调优实战:从原理到案例的深度解析
java·数据库·sql·oracle·性能优化·编辑器
OpsEye19 小时前
Redis 内存碎片的隐形消耗——如何用 memory purge 命令释放空间?
运维·网络·数据库·redis·缓存·内存·监控
施嘉伟19 小时前
一次典型的 SQL 性能问题排查:临时表导致的隐藏性能陷阱
数据库·sql
IT 乔峰19 小时前
分享一个负载均衡的NDB高可用集群架构+部署详细说明
数据库·架构·负载均衡
丁丁点灯o19 小时前
oracle中基于正则表达式匹配规则提取子串的函数REGEXP_SUBSTR
数据库·oracle·正则表达式
木风小助理19 小时前
Android 数据库实操指南:从 SQLite 到 Realm,不同场景精准匹配
jvm·数据库·oracle