导语：合理的sql优化思路--如何缩短SQL调优时间？

概述

当生产环境发生故障或者系统特别慢的时候，这时候你从awr报告拿到有问题的sql，但是优化的时候却优化了很久还没解决，这时候在领导或者客户面前就不太好了。。。那么我们怎么去缩短sql调优的时间，一般优化的思路是怎样呢？

1、先获取有助调优的数据库整体信息

如何缩短 SOL 调优时间，你的思路是什么呢？下面是当我要优化 SOL 时的一般流程：

首先要知道整个数据库的运行情况，前面我已经介绍过数据库 AWR 报告等调优工具，所以这里就不重复说明了，因为 AWR 报告等是在数据库出问题时的利器。可是如果数据库当前没有 出问题呢？其实这个也不一定，很多时候系统没问题是因为你没触发这个问题，其实是有问题的。

比 如某表的索引失效了，某 SOL 访问该列时一定只能走全表扫描；比如某表的属性被设置了并行度，这意昧着所有扫描该表的 SOL 都会并行执行，这；可能会产生严重的资源争用从而让系统瘫痪，比如你的全局临时表被收集了统计信息，访问该表的 SOL 就可能会出现错误的执行计划等等。不过你的 AWR 报告却可能发现不了这些问题，比如该时段和这些对象相关联的 SOL 根本 就没有执行。没发现问题并不代表没有问题，因此我们需要获取所有可能有问题的对象，同时也需要获取所有的相关时段的 AWR 等数据库整体性能报告，获取数据库的整体信息。这里可以考虑用脚本去一键获取，这样就可以提高效率了。

2、快速获取 SQL 运行信息

接下来，在获取到数据库整体信息后，调优的方向就非常明确了，对具体的 SOL 进行调优。执行计划是 SOL 调优的重要武器，通过分析 SOL 计划，我们可以判断 SOL 的访问路径是否 高效，从而进行调整优化。关于执行计划的获取手段有 6 种之多，这是为啥呢？各有啥区别 呢？这部分内容也是在前两天都做了介绍的，大家可以自己再看看。

还需要将执行计划和运行时的统计信息结合在一起分析，这样才会更准确。比如 SOL 产生 了多少逻辑读，多少物理读，是否有排序，是否有递归调用 ， 等等。

3、快速拿到 SQL 关联的信息

当获取到 SOL 的执行计划l后，很多都和该 SOL 对应的表和索引有关。比如当我们怀疑驱动表的顺序有错时，我们就会去看看这些表的实际大小和对应的统计信息是否准确；我们也关心表的类型是什么，比如是否是分区表，在哪个列有分区，分区的类型是什么，等等。

除了关注表的信息，我们也很关心索引的信息。比如看到执行计划中非常适合走索引的查询走了全表扫描，我们就会去看看是否该列无索引，如果发现有，就看看此列索引是否失效 了。一般我们也会关心索引的类型是什么，是 Btree 索引还是位图索引还是函数索引；是单列索引还是组合索引，如果是组合索引，哪列在前，如果索引建在分区表上，我们还关心是全局索引还是局部索引，等等。

这里也可以用脚本将该 SOL 涉及的所有表和列的相关信息直接展现在我们面前，这样，解决问题就非常高效了。

篇幅有限，今天主要分享下sql优化的整体思路，相关脚本抽空再单独介绍下~

后面会分享更多关于DBA方面内容，感兴趣的朋友可以关注下！

本文内容由小葵整理编辑！