这是个终极问题，因为优化本身的复杂性实在是难以总结的，很多时候优化的方法并不是用到了什么高深莫测的技术，而只是一个思想意识层面的差异，而这些都很可能连带导致性能表现上的巨大差异。

所以有时候我们应该先搞清楚需求到底是什么，SQL本身是否合理，这些思考很可能会使优化工作事半功倍。而本文是假设SQL本身合理，从Oracle提供给我们的一些技术手段来简单介绍下Oracle数据库，该如何使用一些现有的技术来优化一个SQL执行的性能。

确定需要优化的SQL文本及当前SQL执行计划

确定SQL涉及的所有表及其索引的相关信息

运行SQL Tuning Advisor 得到调整建议供优化参考

收集表信息

收集索引信息

SQL Profile

物化视图

1. 确定需要优化的SQL文本及当前SQL执行计划

优化之前先确定好需要优化的SQL文本以及当前SQL的执行计划是什么样，注意PL/SQL Developer这类工具F5看到的执行计划很可能并不准确。

相关内容参考：

SQL Tuning 基础概述01 - Autotrace的设定

SQL Tuning 基础概述02 - Explain plan的使用

SQL Tuning 基础概述03 - 使用sql_trace和10046事件跟踪执行计划

2. 确定SQL涉及的所有表及其索引的相关信息

确定查询涉及到的所有表及其索引的相关基础信息。比如:

各表的数据量

表和索引类型

表分区信息，每个分区的数据量

索引字段

索引分区信息

表关联方式

结果集的数量

确定相关信息，以T2表为例：

--普通表/分区表信息select*fromdba_tableswheretable_name='T2';select*fromdba_part_tableswheretable_name='T2';--普通表/分区表的每个分区大约__G大小select(t.bytes/1024/1024)"MB",t.*fromdba_segmentstwheresegment_name='T2';--表数据量信息--普通表的数据量selectcount(1)fromT2;--____数据左右--分区表的某个分区数据量selectcount(*)fromT2partition(P20160101);--____数据左右selectcount(*)fromT2partition(P20160102);--表索引信息--普通表索引及各个索引的索引列select*fromdba_indexeswheretable_name='T2';select*fromdba_ind_columnswhereindex_namein(selectindex_namefromdba_indexeswheretable_name='T2')orderbyindex_name,column_position;--分区表索引及各个索引的索引列select*fromdba_part_indexeswheretable_name='T2';select*fromdba_ind_columnswhereindex_namein(selectindex_namefromdba_part_indexeswheretable_name='T2')orderbyindex_name,column_position;--索引段大小信息--select(t.bytes/1024/1024)"MB",t.*fromdba_segmentstwheresegment_namein(selectindex_namefromdba_part_indexeswheretable_name='T2')orderbysegment_name,partition_name;

3. 运行SQL Tuning Advisor 得到调整建议供优化参考

运行SQL Tuning Advisor 得到调整建议供优化参考, SQL Tuning Advisor得到的优化建议仅供参考，具体如何做还需要结合业务实际情况。

4. 收集表信息

例如收集ZJY用户下T2表的统计信息。（T2是range分区表，按天分区，每天数据量大概80w，存放半年）

SQL>executedbms_stats.gather_table_stats(ownname=>'ZJY',tabname=>'T2',estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,method_opt=>'FORALLCOLUMNSSIZEAUTO',cascade=>TRUE,degree=>16);PL/SQLproceduresuccessfullycompletedExecutedin5896.641seconds

统计信息加锁/解锁

--锁住表的统计信息execdbms_stats.lock_table_stats('ZJY','T2');--解锁表的统计信息execdbms_stats.unlock_table_stats('ZJY','T2');

相关内容参考：

【转载】dbms_stats 导入导出表统计信息

5. 收集索引信息

例如只收集ZJY用户下T2表的索引IDX_T2_1统计信息。（IDX_T2_1是分区索引，包含4个字段）

SQL>executedbms_stats.gather_index_stats(ownname=>'ZJY',indname=>'IDX_T2_1',estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,degree=>8);PL/SQLproceduresuccessfullycompletedExecutedin44.312seconds

有时还很可能需要在业务闲时在线创建新的索引

--不记录日志在线并行创建单列索引IDX_T2_2（并行度视生产环境当前的CPU资源使用情况来确定合理的值）createindexIDX_T2_2onT2(start_time)tablespaceDBS_I_JINGYUnologgingparallel12online;alterindexIDX_T2_2noparallel;alterindexIDX_T2_2logging;

6. SQL Profile

SQL Profile是10g中的新特性，作为自动SQL调整过程的一部分。SQL Profile是一个对象，它包含了可以帮助查询优化器为一个特定的SQL语句找到高效执行计划的信息。这些信息包括执行环境、对象统计和对查询优化器所做评估的修正信息。它的最大优点之一就是在不修改SQL语句和会话执行环境的情况下影响查询优化器的决定。SQL Profile中包含的并非单个执行计划的信息，SQL Profile不会固定一个SQL语句的执行计划。当表的数据增长或者索引创建、删除，使用同一个SQL Profile的执行计划可能会改变，而存储在SQL Profile中的信息会继续起作用。所以，经过一段很长的时间之后，它的信息有可能会过时，需要重新生成。

相关内容参考：

【转载】sql_profile的使用

【转载】sql_profile快速绑定脚本

7. 物化视图

Oracle的物化视图可以用于预先计算并保存（表连接或聚集等耗时较多的操作的）结果，所以合理使用物化视图，会在执行查询时避免进行这些耗时的操作，从而快速的得到结果。