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

来源：这里教程网时间：2026-03-03 23:05:26 作者：

在生产系统里，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 工程师”的分水岭。