Oracle里那些能让SQL跑得快点儿的实用技巧分享给你

最重要的一点是,绝大多数SQL跑得慢，问题不在于Oracle数据库本身不够强大，而在于我们写的SQL语句和表结构设计没有充分利用好Oracle的能力，优化的核心思路是“帮数据库减负”和“为数据库指路”。

学会看执行计划——知道慢在哪里

这是所有优化的第一步,就像医生看病要先做检查，在SQL开发工具里（比如PL/SQL Developer），选中你的SQL语句，按F5键或者点击“解释计划”的按钮，你会看到一个树状图，你不用完全看懂所有专业名词，重点关注以下几点：

• 全表扫描（Full Table Scan）：这意味着数据库为了找你想要的数据，把整张表从头到尾翻了一遍，如果表有几百万行，这就像在图书馆找一句话却翻遍了所有的书，效率极低，我们的目标就是尽量避免这种情况。
• 成本（Cost）：执行计划会给出一个成本数值，这个数字本身意义不大，但当你对SQL进行修改后，对比修改前后成本值的变化，如果成本显著下降，通常说明你的优化是有效的。
• 耗时的操作：注意看哪个步骤的“行数（Rows）”突然变得很大，或者哪个操作看起来特别耗时（排序（Sort）”），这里往往就是瓶颈。

（来源：Oracle官方文档关于使用EXPLAIN PLAN的说明，以及广泛被DBA推荐的性能诊断方法）

给查询加索引——像给书加目录

这是最立竿见影的优化手段,索引就是数据的“目录”。

1. 在WHERE子句的列上加索引：如果你的查询经常用WHERE name = ‘张三’或者WHERE department_id = 10这样的条件，那么在name和department_id列上创建索引，数据库就能直接定位到数据，而不是全表扫描。
2. 在连接条件（JOIN）的列上加索引：多表连接时，比如FROM A JOIN B ON A.id = B.a_id，确保A.id和B.a_id这两个连接字段上都有索引，连接速度会快很多。
3. 联合索引要注意顺序：如果一个查询条件经常同时使用多个列，比如WHERE city=’北京’ AND age > 30，可以创建一个(city, age)的联合索引，这里顺序很重要，查询时必须从索引的最左列（这里是city）开始使用，索引才会生效，如果只查age>30，这个联合索引是无效的。
4. 索引不是越多越好：索引就像书的目录，每多一个目录，写书（插入、更新、删除数据）的时候就要多更新一次目录，会影响写入速度，只给最核心、最频繁的查询条件加索引。

（来源：常见的数据库索引优化原则，在《Oracle高效设计》等书籍及AskTOM网站均有强调）

写好SQL语句——避免傻大黑粗的写法

很多时候,换一种写法，性能天差地别。

1. 用EXISTS代替IN：当子查询返回的结果集很大时，IN操作的效率会很低，改用EXISTS通常会更好。

   • 慢的写法：SELECT * FROM employees WHERE department_id IN (SELECT department_id FROM departments WHERE location_id = 1700)
   • 快的写法：SELECT * FROM employees e WHERE EXISTS (SELECT 1 FROM departments d WHERE d.department_id = e.department_id AND d.location_id = 1700)
   • 原因是EXISTS只要找到一个匹配项就会返回真，而IN需要处理整个结果集。

2. 避免在索引列上使用函数或计算：这会让索引失效。

   • 慢的写法：WHERE TO_CHAR(create_date, ‘YYYY-MM-DD’) = ‘2023-10-26’ （即使create_date有索引，因为用了TO_CHAR函数，索引也用不上）
   • 快的写法：WHERE create_date >= TO_DATE(‘2023-10-26’, ‘YYYY-MM-DD’) AND create_date < TO_DATE(‘2023-10-27’, ‘YYYY-MM-DD’) （直接使用日期范围，索引有效）

3. **尽量减少SELECT **：只取你需要的列，`SELECT 会把所有列的数据都拿出来，如果有一些大字段（如CLOB类型），会白白消耗大量网络带宽和内存，明确写出需要的列名，如SELECT id, name, phone`。

4. 用UNION ALL替代UNION：如果确认两个结果集没有重复记录，一定要用UNION ALL，因为UNION会为了去重而进行排序操作，非常耗时，而UNION ALL直接合并，效率高得多。

   

（来源：大量SQL编程最佳实践指南和DBA经验分享，如Oracle社区论坛中的常见问题解答）

设计和架构层面的考虑

这些是更根本的方法,可能在设计阶段就要想好。

1. 分区表：对于非常大的表（比如上亿行），可以把它按某种规则（如时间范围）分成多个物理上独立的小部分，查询时，如果条件里带了分区键，数据库就可以只扫描相关的那个小分区，而不是整个大表，这叫“分区裁剪”，效果极其显著。
2. 定期统计信息更新：Oracle优化器依靠表的统计信息（比如表有多大、数据是怎么分布的）来决定怎么执行SQL最快，如果统计信息过时了，优化器可能会选错索引，制定一个很慢的执行计划，需要定期（比如每天或每周）让数据库自动收集统计信息。
3. 使用绑定变量：在程序里拼SQL字符串时，不要直接拼接值，而要使用占位符（绑定变量），这不仅能防止SQL注入攻击，更能极大提升数据库性能，因为每次SQL文本不同，数据库会认为这是一个全新的SQL，需要重新解析（硬解析），解析是非常消耗CPU的操作，使用绑定变量后，SQL文本不变，只是参数值变化，数据库可以复用之前的解析结果（软解析）。

（来源：Oracle性能调优权威指南以及针对高并发应用系统的优化建议）

让SQL跑得快,关键在于：先看执行计划找到瓶颈，然后通过创建合适的索引、优化SQL写法来解决问题，并在系统设计之初就考虑分区等策略，这是一个持续的过程，需要不断地测试、观察和调整，希望这些实实在在的技巧能帮到你。