sql优化的方法及思路-ag凯发k8国际
当生产环境发生故障或者系统特别慢的时候，这时候你从awr报告拿到有问题的sql，但是优化的时候却优化了很久还没解决，这时候在领导或者客户面前就不太好了。。。那么我们怎么去缩短sql调优的时间，一般优化的思路是怎样呢？
如何缩短 sol 调优时间，你的思路是什么呢？下面是当我要优化 sol 时的一般流程：
首先要知道整个数据库的运行情况，前面我已经介绍过数据库 awr 报告等调优工具，所以这里就不重复说明了，因为 awr 报告等是在数据库出问题时的利器。可是如果数据库当前没有 出问题呢？其实这个也不一定，很多时候系统没问题是因为你没触发这个问题，其实是有问题的。
比 如某表的索引失效了，某 sol 访问该列时一定只能走全表扫描；比如某表的属性被设置了并行度，这意昧着所有扫描该表的 sol 都会并行执行，这；可能会产生严重的资源争用从而让系统瘫痪，比如你的全局临时表被收集了统计信息，访问该表的 sol 就可能会出现错误的执行计划等等。不过你的 awr 报告却可能发现不了这些问题，比如该时段和这些对象相关联的 sol 根本 就没有执行。没发现问题并不代表没有问题，因此我们需要获取所有可能有问题的对象，同时也需要获取所有的相关时段的 awr 等数据库整体性能报告，获取数据库的整体信息。这里可以考虑用脚本去一键获取，这样就可以提高效率了。
接下来，在获取到数据库整体信息后，调优的方向就非常明确了，对具体的 sol 进行调优。执行计划是 sol 调优的重要武器，通过分析 sol 计划，我们可以判断 sol 的访问路径是否 高效，从而进行调整优化。关于执行计划的获取手段有 6 种之多，这是为啥呢？各有啥区别 呢？这部分内容也是在前两天都做了介绍的，大家可以自己再看看。
还需要将执行计划和运行时的统计信息结合在一起分析，这样才会更准确。比如 sol 产生 了多少逻辑读，多少物理读，是否有排序，是否有递归调用 ， 等等。
当获取到 sol 的执行计划l后，很多都和该 sol 对应的表和索引有关。比如当我们怀疑驱动表的顺序有错时，我们就会去看看这些表的实际大小和对应的统计信息是否准确；我们也关心表的类型是什么，比如是否是分区表，在哪个列有分区，分区的类型是什么，等等。
除了关注表的信息，我们也很关心索引的信息。比如看到执行计划中非常适合走索引的查询走了全表扫描，我们就会去看看是否该列无索引，如果发现有，就看看此列索引是否失效 了。一般我们也会关心索引的类型是什么，是 btree 索引还是位图索引还是函数索引；是单列索引还是组合索引，如果是组合索引，哪列在前，如果索引建在分区表上，我们还关心是全局索引还是局部索引，等等。
这里也可以用脚本将该 sol 涉及的所有表和列的相关信息直接展现在我们面前，这样，解决问题就非常高效了。
篇幅有限，今天主要分享下sql优化的整体思路，相关脚本抽空再单独介绍下~
后面会分享更多关于dba方面内容，感兴趣的朋友可以关注下！
总结
以上是ag凯发k8国际为你收集整理的sql优化的方法及思路_合理的sql优化思路--如何缩短sql调优时间？的全部内容，希望文章能够帮你解决所遇到的问题。
- 上一篇： 根据条件查询某条记录的条数_「性能与架构
- 下一篇：