数据库性能优化（database tuning）性能优化绝不仅仅只是索引

Posted 2020-10-31 数据库生态圈（RDB & NoSQL & Bigdata）

一毕业就接触优化方面的问题，专业做优化也有至少5年之多的时间了，可现在还是经常听到很多人认为优化很简单，就是建索引的问题，这确实不能怪大家，做这行20多年的时间里，在职业生涯的每个阶段，几乎都能听到这样的声音，在很多书上也看到过这样的说法，但这里我想告诉大家：优化绝不只是建索引，优化也不是很简单的事儿，这项工作需要全面的数据库基础知识，深刻的概念理解，还要有丰富的实践经验。

数据库的优化，大体可以分为OS、DB和SQL层面的优化。先抛开OS和DB层面不说，我们就先说SQL语句的优化（SQL TUNING），说到SQL的优化，就让我们不得不提到执行计划（explain plan），所有的关系型数据库（oracle,db2,sqlserver,mysql,postgresql,gp等），针对SQL语句，都有相应的执行计划，只是表现形式不同而已。执行计划里包括了多个节点或步骤，根据SQL复杂度的不同，节点或多或少，这些节点里，有多种数据的访问方法，也有多种节点之间数据的计算方法，而索引，只是多种数据访问方法里的一种而已，再抛开那些计算节点和其他数据访问节点，仅仅索引访问数据的方法，又分为很多种，大家可以看看，抛开了这么多方面和内容，仅仅索引还有这么多内容学习和研究。

说到了访问数据的方法，最常见的就是全表扫描和索引访问了，现在很多人，甚至很多IT人一见到全表扫描就认为执行计划出现了问题，甚至大声惊呼，好像发现了新大陆，其实，全表扫描有自己的适用场景，而索引访问也有自己的适用场景，并不是任何时候通过索引访问数据才是最优的，最浅显的，访问表里的大部分数据，全表扫描就可能比索引访问要好些，还有一点，就是索引的cluster factor，当这个值很高的时候（也许很多朋友注意到，有时一个SQL的逻辑读比整张表都大很多，仅此而已），即使你访问的数据比例不大，也可能走全表扫描，而在多个不同字段上建的索引存在的情况下，cluster factor的问题几乎是不可避免的，所以，要想真正的掌握优化，我们必须知道并深入理解数据库涉及的基础知识和概念，只有这样，我们才能搞清楚，什么情况下，什么样的访问方法和算法是最合适的。

SQL TUNING确实对职业人员的要求较高，但这只是解决了应用层面的问题，不可否认，在很多情况下，系统性能甚至故障是由SQL导致的，但在很多情况下，即使把SQL TUNING的再好，也是解决不了性能问题，这就要求我们对OS和DB层面进行整体分析和调优。

这篇文章到此为止，只是告诉大家，调优不仅仅是索引问题，还有很多方面需要我们去学习和研究，至于OS、DB和SQL TUNING调优的具体方法和步骤，请查阅本博客其他文章。