别只会看执行计划,得动手改写
很多做 Oracle 运维或后端开发的人,遇到慢查询的第一反应是加索引、调统计信息或者改优化器参数。这套资料针对的是另一个更硬核的缺口:SQL 写法本身就有结构性问题,导致多扫了几遍表,此时不改逻辑根本救不回来。它不讲基础语法,也不讲体系结构,只盯着生产环境里最容易拖垮性能的几类写法,教你怎么在不改表结构、不加索引的前提下,靠等价改写把全表扫描次数压下去。适合已经能独立写复杂多表关联、能看懂执行计划里过滤行数和成本估算的人来补课。如果你连标量子查询和分析函数的语义都还没理清,建议先去补基础再来看,否则跟不上里面改写前后的对比逻辑。
先吃透标量子查询和分析函数这两块
建议按资料包里给定的顺序看,不要跳。第一节讲删除异常记录的改写,这是热身,重点看它怎么把一个原本要多次自连接去重的写法,换成单次扫描搞定。紧接着的标量子查询和 update 语句里的标量子查询是核心痛点:很多人喜欢在 select 列表里塞标量子查询,或者在 update 的 set 里用相关子查询,这会导致驱动表每出一行就被扫描一次内部结果集,数据量一大直接卡死。资料里会演示怎么把这些标量子查询改写成等价的外连接或者内联视图,让 Oracle 能用哈希连接一次性处理。最后两节聚焦分析函数,重点看怎么用 row_number、lag 这类函数替代原本需要多次扫描同一张表才能算出来的逐行比对结果。看的时候不要只盯着最终的改写代码,必须自己复现改写前的烂 SQL,跑一遍执行计划,看清楚逻辑读块数到底降在哪里。
学完能独立做什么以及怎么练
学完这套案例,你应该能拿到一条生产环境里跑了几十秒的 SQL,先判断它是不是属于标量子查询滥用或者多表自连接导致的重复扫描,然后动手把它等价改写成带分析函数的写法或者改写后的 join 形式,并且能用执行计划证明改写后的逻辑读确实降下来了。练习的时候,拿资料包里的案例当模板,自己在测试库造十万行以上的数据,先跑原始 SQL 记录执行时间和 consistent gets,再跑改写后的 SQL 做对比。如果改写后结果对不上,说明你把语义改错了,这时候回头去抠分析函数的 partition by 和 order by 的边界条件。别指望看一遍视频就能记住所有改写套路,这些案例必须自己敲一遍 SQL Plus 或者其他客户端,真正看到执行计划里的代价数字掉下来,才算补上了这个缺口。
课程目录
1-1 [SQL改写优化] 删除异常记录改写案例 (21:00) 1-2 [SQL改写优化] 标量子查询介绍及改写案例 (22:50) 1-3 [SQL改写优化] update语句中的标量子查询介绍及改写案例 (22:39) 1-4 [SQL改写优化] 使用分析函数减少表扫描次数的改写案例1 (11:15) 1-5 [SQL改写优化] 使用分析函数减少表扫描次数的改写案例2 (22:56)





