开篇：一场由SQL引发的"血案"

凌晨2点，报警群突然炸了——某核心业务库CPU飙到98%，交易系统响应延迟突破10秒。
我顶着黑眼圈打开AWR报告，发现一条"神秘SQL"正以每秒200次的频率疯狂吞噬着IO资源。
开发同事在群里弱弱发话：“这SQL跑测试环境明明很快啊…”

今天，我们就来揭秘那些让DBA“血压飙升”的烂SQL，以及如何用专业技巧力挽狂澜。以下全是真实案例，建议转发给“肇事”同事！

案例1：多表关联的“混乱连接”

烂SQL场景：

财务系统多表关联查询耗时8分钟，表关联紊乱和FILTER操作

SELECT * FROM orders o, payments p   
WHERE o.order_id = p.order_id(+)  
AND o.user_id IN (SELECT user_id FROM blacklist);

问题分析：

1.外连接滥用，(+)语法导致优化器无法识别最佳连接顺序。‌

2.子查询未合并，IN子查询触发FILTER操作，循环执行百万次

优化方案：

改用ANSI JOIN语法：明确连接逻辑
SELECT * FROM orders o  
LEFT JOIN payments p 
ON o.order_id = p.order_id  
WHERE EXISTS
(SELECT 1 FROM blacklist 
b WHERE b.user_id = o.user_id);  
1.子查询合并，通过HASH JOIN替代FILTER循环
2.LEFT JOIN‌：LEFT JOIN会先执行连接操作，
然后再进行过滤，‌(+)符号‌：使用(+)符号时，
查询的执行顺序是先过滤后连接。

案例2：NULL值查询的“隐形杀手”

烂SQL场景：

某报表系统按“未填写备注”条件查询时，10GB表全表扫描耗时180秒

SELECT * FROM contracts 
WHERE remark IS NULL;

问题分析：

单列索引失效：Oracle默认不索引NULL值，导致全表扫描。

复合索引漏洞：现有索引idx_contract未包含NULL值标识列。

优化方案：

1.创建NULL值专用索引：
通过常量占位符强制索引NULL记录
CREATE INDEX idx_remark_null 
ON contracts(remark, 0);  
2.改写查询条件：利用索引覆盖扫描
SELECT * FROM contracts 
WHERE remark IS NULL AND 0 = 0;

案例3：LOB字段全表扫

问题SQL：

SELECT * FROM contract 
WHERE PDF_CONTENT LIKE '保密协议%';

症状：频繁扫描CLOB字段拖垮IO

优化方案：

CREATE INDEX idx_contract_content ON contract(PDF_CONTENT)  
INDEXTYPE IS CTXSYS.CONTEXT;  
SELECT * FROM contract 
WHERE CONTAINS(PDF_CONTENT, '保密协议') > 0; 
说明：INDEXTYPE IS CTXSYS.CONTEXT
是Oracle Text组件中的一种全文索引类型，
专为大文本字段的高效模糊查询设计

案例4：批量操作与事务

1.大事务导致UNDO表空间爆满
DELETE FROM billion_rows_table 
WHERE create_time < SYSDATE-365;
优化：分批次删除（每1万条提交），UNDO占用大大减小
2.低效的INSERT ALL批量插入
INSERT ALL INTO table_a VALUES (...) 
SELECT * FROM dual;  
优化：改用INSERT /*+ APPEND */直接路径插入，
速度提升10倍
3.TRUNCATE与DELETE选择失误
DELETE FROM error_data; 
-- 千万级数据 ,归档剧增
优化：改用TRUNCATE或临时表方案

结语：DBA的生存法则

“烂SQL是DBA最好的老师，每个故障都是技术升级的契机。与其抱怨‘这届开发不行’，不如用工具链构筑护城河——毕竟，预防的成本永远低于抢救！”

"每个烂SQL都是送上门的教学案例，每次性能危机都是展现价值的战场。

记住：我们不是修电脑的，我们是数字世界的急诊科医生！"