数据库开发常识（10.6）——SQL性能判断标准及索引误区（1）

10.6.  数据库开发常识

作为一名专业数据库开发人员，不但需要掌握数据库开发相关的语法和功能实现，还要掌握专业数据库开发的常识。这样，才能在保量完成工作任务的同时，也保质的完成工作任务，避免了为应用的日后维护埋下性能和稳定性方面的隐患。可遗憾的是，现实中，很大一部分的专业开发人员只能做到保量的完成工作任务，而做不到既保量也保质。这也就不难解释，现实中，为什么很多应用系统上线后，性能和稳定性等方面还频繁的出现问题。

这里所谓的数据库开发常识，指经过长期不断的基础理论和实践经验的积累与沉淀，专业人员获得的数据库开发方面的规律和结论，用以帮助提高数据库开发工作的效率，更重要的是保证开发成果的质量。

下面仅就实际工作中最常遇到的，也是最常用到的数据库开发常识进行介绍和说明，以期对各位有所启发和帮助。

10.6.1. 判断SQL性能的标准

目前几乎所有高版本关系库（RDB，Relational Database）的优化器都是CBO（见本专栏6.1节）的，那么，判断一条SQL语句性能好坏的标准只有一个，那就是执行计划（Explain Plan）及其成本。拿到一条SQL语句的执行计划前，我们没办法准确判断其性能的好坏及问题所在。因此，我们不但要掌握获取执行计划的方法，也要学会查看和分析执行计划，起码要会查看和分析简单的执行计划。

10.6.2. 索引相关误区

1）走索引一定是最优的。

查看和分析执行计划时，有一个大家似乎公认的调优原则，那就是：走FTS就一定是错的，存在性能问题的；走index就一定是对的，是最优的。针对这种观点，我只能说：不一定，要看具体的实际情况。大家先考虑下为什么这么说？为了便于理解，我们考虑两个比较极端的场景。

• 第一个场景，假设表里的数据比较少，一个数据块就能容纳，并且，表的相应列上有B*Tree索引，假设索引也只有一个数据块。我们哪怕只访问表里的一条数据时，当不走索引时，我们只需读取一个数据块就可以，那就是表的所有数据块；如果走索引，那么，就得读取两个数据块，先读索引块，然后，读表的数据块，大家比较下，哪个成本高哪个成本低呢？
• 另一个场景，假设一个表有100个数据块，索引有20个数据块。当我们读取表里90%的数据时，如果不走索引，那么，只需要读取表的100个数据块；而如果走索引，就得读取至少18+90=108个数据块。这么看，走索引似乎有点得不偿失，大家比较下，该场景下，哪个成本高哪个成本低呢？
• 当然，以上只是通过这两个极端、理想的场景说明一个道理：走index未必最优，走FTS也未必就有问题。现实中，场景和成本计算都要比这里复杂得多，也还会涉及到其他概念和因素，例如：FTS的并行多块读，index的顺序读，索引的聚簇因子（Cluster Factor）等，这些都会影响SQL语句的最终执行计划。

--注：

      1）大家思考下，当读取相同的数据块数时，并行多块读和顺序读的区别和结果分别是什么？

      2）这里大家需要思考一个问题，那就是在现实工作中，有时查询一张表所读取的数据块数比整张表的数据块数还要多，有时是整张表数据块数的几倍甚至几十倍，为什么？

2）索引可随便创建

现实工作中，很多公司或机构的开发库、测试库甚至生产库的管理和权限控制，既很不严格，也非常不规范。所有或部分员工都可以随便访问数据库，且都拥有修改数据、建立、删除索引及其他对象，甚至数据库的最高权限。现实中，由于员工随便删除索引导致事故的案例并不稀奇，因员工随便乱建索引而引发数据库负载居高不下、性能陡降，甚至引起严重事故的现象也是屡见不鲜。

因此，规范数据库管理和严控数据库权限，尤其是机构生产库的管理和权限，会很大程度上避免事故的发生和减少由此带来的损失。由此，也杜绝了无序的乱建索引而引发的一系列问题和后果。现实工作中，除非确定索引能极大的改善某个应用模块或操作的性能，且不会对其他应用模块或操作带来负面影响，否则，还是三思而后行，最好通过规范的流程和渠道去分析、确定和实施索引策略。

--注：

      1）大家思考下，删除索引为什么会导致事故？随便建索引又为什么会导致负载居高不下、性能陡降，甚至引起事故？