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 的底气。