再谈数据库优化（database tuning）的真谛和误区

当今各行业信息量呈现爆炸式增长，因此，数据库优化也就显得弥足重要。随着数据库性能问题的出现，每位用户为了解决出现的问题，不得不满网上到处搜索优化的”灵丹妙药“和捷径，于是，就出现了各种各样的条条框框和金科玉律，以至于这些观点流传很广，对广大用户的影响也很大，例如：

1、SQL语句必须怎么写和注意什么才能性能好，某种写法会比其他写法性能好。这种说法，虽然不能说完全是错的，但也不能说是对的。我们看看数据库优化器的演化和发展历程，就能明白这么说的原因。低版本的数据库优化器是基于规则（rule）的，所谓基于规则，就是SQL语句的执行计划是和SQL的语法息息相关的，也就是说，SQL语句的写法决定了最终的执行计划，也就决定了该SQL语句的性能状况。随着优化器的不断进化和发展，目前所有关系库的优化器都是CBO，也就是基于成本的优化器，顾名思义，在这种优化器中，SQL语句的执行计划和写法几乎没什么关系，而是根据优化器计算出的成本来选择出最好的执行计划的，哪个执行计划成本最低，那么就用哪个执行计划，因此，性能也最好。不可否认，最先进的关系库优化器，例如：Oracle12c，虽然智能化程度已经非常高，机制和算法已经非常先进和完善，产生的执行计划也不可能100%的是最高效的，其中的因素很多，这里不意义论述。甚至在某些场景下，SQL语句的写法确实会影响最终的执行计划，从而影响SQL语句的性能好坏。

2、我经常听到现场的用户惊呼：不好了，数据库中有锁。针对这种情况，我曾经一遍遍的和他们讲，关系库中存在锁是很正常的，在一个高负载、高并发的关系库中，时时刻刻都会存在一些、甚至大量的锁，这是关系库的核心机制，在这种高负载、高并发的数据库上，有锁是正常的，没有锁是不正常的，所以，数据库中存在锁也就不值得奇怪和吃惊了。存在锁没什么奇怪的，关键是看看是否正常，那么，怎么看锁是否正常，针对每种关系库，都有自己一套理论和办法来查询和分析，这里不再赘述。

3、很多用户对SQL调优（SQL TUNING）情有独钟，不管遇到什么数据库的问题，都会想到SQL调优上去。确实，SQL调优确实可以在很大程度上改善数据库的性能，改善幅度也可能是最大的，但在对SQL进行调优前，要看看其他层面或方面是否正常，在确定了性能问题确实是因为SQL引起的，在进行SQL调优，也许才会起到有的放矢，从而起到最好的优化作用。除了SQL层面，还有很多层面和方面会影响数据库性能，例如：OS层面的性能也会影响到数据库性能，因为它是数据库的平台和容器；同时，如果数据库系统存在问题，单纯去进行SQL 调优，可能也是解决不了问题的。OS和DB层面存在问题，导致数据库性能问题的案例在现实中还是经常会遇到的。所以，在SQL调优前，固定其他层面和方面的因素是必须的。

4、数据库存在性能问题，经常听到很多人立刻问道：数据量多大？如果听说上亿或者更大，马上就说：这么大数据量，性能当然会有问题，于是乎那些问问题的人马上就会心服口服。其实这里面会有错误的认识，数据量大是导致出现性能问题的基础，如果数据库里没数据，也就不会出现性能问题，但即使有几十亿，上百亿，上千亿数据量，我只取其中的一条或很少部分数据，且计划正确，也未必就会存在性能问题。也经常有人说，我们上百亿数据量，或PB级数据量，能做到毫秒级的速度，这明显是内行人忽悠外行人，或者外行人忽悠外行人，能不能到毫秒级，和多方面因素有关，还有关键看怎么用数据，有些需求，几百万甚至更少就能出现严重的性能问题，而有的需求，几百亿上千亿，性能也不是问题，但现实中，偏偏很多人被这种说法给说服了，而且心悦诚服的虔诚样子，每次我对这些类似说法提出质疑，从来没得到过正面回应。所以，数据量是性能问题的诱因，但非必然。两本书，一本有几十页，另一本有几千页，通过目录去查找某一章节，速度也许不会真的有数量级的差别，但因为目录大小不同，性能也许会有点差别，一个道理。

以上仅仅举出了现实中最常见的几种情况和误解，其他类似的情况或案例也许会很多，这里不再一一赘述。

所谓优化，不是条条框框，也不存在金科玉律，而是基于深厚理论基础，进行丰富实践的理解和总结，理论和实践缺一不可。其实，现实中很多行业都是一样的，优化从来不是一个入门级的技术，它是一种熟能生巧，活学活用的技能，因此，对于一个初学者来说，应该打好基础，不断实践，在实践中不断总结，积累到一定程度，就能解决一些性能方面的问题，不可否认，优化也有一定的技巧和规律可循，但需要基础才能领会和掌握。

基于个人理解，希望能对大家有所帮助。