Oracle里头用hints调优那些事儿，实操演练和技巧分享

说到Oracle数据库调优,hints（提示）绝对是一个让DBA和开发者又爱又恨的工具，爱的是，它有时候像一把万能钥匙，能强行让不走寻常路的优化器“改邪归正”；恨的是，用不好反而会适得其反，把慢查询变得更慢，今天咱们就抛开那些厚厚的官方手册，聊点实操中的心得体会。

得明白hints是个啥玩意儿，它不是命令！ 这一点非常重要，根据Oracle官方文档（来源：Oracle Database SQL Tuning Guide）的说法，hints只是给优化器的一个“强烈建议”，优化器这个家伙很聪明，它会根据表的统计信息、数据分布、系统负载等一大堆因素，自己决定怎么执行SQL最快，但有时候它也会犯傻，比如统计信息过时了，或者它预估的成本模型跟实际情况不符，这时候，就得靠我们人工介入，用hints给它指条明路。

hints怎么用？语法很简单，但位置有讲究。 标准的写法是在SELECT、UPDATE、DELETE或者INSERT关键字后面，紧跟着写一个注释块，注释块里以号开头。

SELECT /*+ INDEX(emp emp_deptno_idx) */ empno, ename FROM emp WHERE deptno = 10;

这句的意思就是：“优化器大哥，求你了，在查emp表的时候，尽量用emp_deptno_idx这个索引吧。” 你可别把它写到语句最后面，那可就白写了。

分享几个实战中最常用的hints和踩过的坑。

第一个，/*+ INDEX */ 系列。 这是使用频率最高的hints之一，有时候你明明建了索引，优化器却偏偏选择全表扫描（FULL TABLE SCAN），原因可能是指定索引的区分度不高，或者统计信息认为全表扫描更快，这时你就可以用INDEX提示。

• 技巧1： 直接用/*+ INDEX(table_name index_name) */指定死用一个索引，这招比较狠，通常是在你非常确定这个索引最优的时候用。
• 技巧2： 用/*+ INDEX_FFS(table_name index_name) */，FFS是Fast Full Index Scan的缩写，当你的查询只需要索引列的数据时（比如SELECT deptno FROM emp），用这个提示会让优化器只扫描索引块，而不去碰表的数据块，速度会快很多，因为索引块通常比数据块小得多。
• 踩坑记录： 我曾经遇到一个情况，一个表每天有大量删除和插入，导致索引的聚簇因子（Clustering Factor）变得很差，优化器本来聪明地选择了全表扫描，我非要手贱加上INDEX提示，结果查询时间从2秒飙升到20秒，加hints前一定要先搞清楚优化器为什么那么选。

第二个，/*+ LEADING */ 和 /*+ USE_NL */。 这俩是控制表连接顺序和连接方式的黄金搭档。

• 实操场景： 假设你要连接A表和B表，A表很小（比如100条记录），B表很大（100万条记录），理想的连接方式是“嵌套循环”（Nested Loop）：先把小表A的100条数据抓出来，然后拿着这100个键值去大表B的索引里快速查找，这就像你先记下100个名字，然后挨个去电话本里查，比翻遍整个电话本快多了。
• 怎么写： SELECT /*+ LEADING(A) USE_NL(B) */ ... FROM A, B WHERE A.id = B.a_id，这里LEADING(A)是告诉优化器：“先以A表为驱动表”，USE_NL(B)是告诉它：“用嵌套循环的方式去连接B表”。
• 踩坑记录： 如果反过来，你把大表B作为驱动表，那灾难就发生了：优化器会先扫描B表的100万条记录，然后对每一条都去A表里做一次查询，虽然A表小，但100万次查询也是致命的。LEADING提示的顺序至关重要。

第三个，/*+ PARALLEL */。 这是应对大数据量查询的“核武器”，它能让一个任务被多个CPU进程同时处理，充分利用硬件资源。

• 怎么用： SELECT /*+ PARALLEL(emp, 4) */ * FROM emp; 意思是让查询emp表时使用4个并行进程。
• 重要警告： 这东西不能乱用！它是一把双刃剑，在OLTP（联机事务处理）系统的高峰期，如果你开了一个并行度很高的查询，可能会瞬间抢光数据库的CPU和I/O资源，导致其他正常交易卡死，这简直就是一场灾难，它通常只用在后台跑批处理、数据仓库查询等允许消耗大量资源的场景，用之前一定要评估对系统整体的影响。

也是最重要的：hints是最后的手段。

根据很多资深DBA的经验分享（来源：Oracle社区论坛及技术博客），不要一上来就想着用hints解决问题，调优的正确步骤应该是：

1. 检查SQL写法： 有没有不必要的子查询？连接条件是否正确？
2. 检查统计信息： 是不是很久没收集了？用DBMS_STATS.GATHER_TABLE_STATS更新一下统计信息，可能问题就解决了。
3. 检查索引设计： 是不是缺了合适的索引？
4. 如果以上都做了，优化器的执行计划依然很糟糕，并且你完全理解为什么它糟糕以及你的hints为什么更好时， 再考虑谨慎地使用hints。

Oracle的hints功能强大,但需要深厚的经验才能驾驭，把它当成急救室的强心针，而不是日常的维生素，多实践，多测试，同时怀有对优化器的敬畏之心，这样才能真正玩转hints调优。