首席DBA用SQL洪荒之力，造一把通向数据库的钥匙(3)

这里来自阿里-叶正盛的一篇博客里的一张图,相信很多人都看过.这里提出了经典的漏斗优化法则,高度是指我们投入的资源,宽度是指可能实现的收益.从图中可见,“减少数据访问”是投入资源最少,而收益较多的方式；“增加硬件资源”是相对投入资源最多,而收益较少的一种方式.受时间所限,这里不展开说明了.

这是我总结的一个优化法则,简称为“DoDo”法则.

• 第一条,“Do Less or not do!”翻译过来,就是尽量让数据库少做工作、甚至不做工作.

怎么样来理解少做工作呢?比如创建索引往往可以提高访问效率,其原理就是将原来的表扫描转换为索引扫描,通过一个有序的结构,只需要少量的IO访问就可以得到相应的数据,因此效率才比较高.这就可以归纳为少做工作.

怎么样来理解不做工作呢?比如在系统设计中常见的缓存设计,很多是将原来需要访问数据库的情况,改为访问缓存即可.这样既提高了访问效率,又减少了数据库的压力.从数据库角度来说,这就是典型的不做工作.

• 第二条,“If must do,do it fast!”翻译过来,如果数据库必须做这件事件,那么请尽快做完它.

怎么样来理解这句话呢?比如数据库里常见的并行操作,就是通过引入多进程来加速原来的执行过程.加速处理过程,可以少占用相关资源,提高系统整体吞吐量.

SQL的执行过程比较复杂,不同数据库有一定差异.下面介绍以两种主流的数据库(Oracle、MySQL)介绍一下.

1. 用户提交了一条SQL语句
2. 数据库按照SQL语句的字面值计算出一个HASH值
3. 根据HASH值,判断一下在数据库缓冲区中是否存在此SQL的执行计划.
4. 如果不存在,则需要生成一个执行计划(硬解析过程),然后将结果存入缓冲区.
5. 如果存在的话,判断是否为相同SQL(同样HASH值的语句,可能字符不相同；即使完全相同,也可能代表不同的语句.这块不展开说了)
6. 确认是同一条SQL语句,则从缓冲区中取出执行计划.
7. 将执行计划,交给执行器执行.
8. 结果返回给客户端.

1. 客户提交一条语句
2. 现在查询缓存查看是否存在对应的缓存数据,如有则直接返回(一般有的可能性极小,因此一般建议关闭查询缓存).
3. 交给解析器处理,解析器会将提交的语句生成一个解析树.
4. 预处理器会处理解析树,形成新的解析树.这一阶段存在一些SQL改写的过程.
5. 改写后的解析树提交给查询优化器.查询优化器生成执行计划.
6. 执行计划交由执行引擎调用存储引擎接口,完成执行过程.这里要注意,MySQL的Server层和Engine层是分离的.
7. 最终的结果有执行引擎返回给客户端,如果开启查询缓存的话,则会缓存.

在上面的执行过程描述中,多次提高了优化器.它也是数据库中最核心的组件.下面我们来介绍一下优化器.

上面是我对优化器的一些认识.优化器是数据库的精华所在,值得DBA去认真研究.但是遗憾的是,数据库对这方面的开放程度并不够.(相对来说,Oracle还是做的不错的)

这里我们看到的MySQL的优化器的工作过程,大致经历了如下处理：

1. 词法分析、语法分析、语义检查
2. 预处理阶段(查询改写等)
3. 查询优化阶段(可详细划分为逻辑优化、物理优化两部分)
4. 查询优化器优化依据,来自于代价估算器估算结果(它会调用统计信息作为计算依据)
5. 交由执行器执行

此图是DBAplus社群MySQL原创专家李海翔对比不同数据库优化器技术所总结的.从这里可以看出：

1. 不同数据库的实现层次不同,有些支持、有些不支持
2. 即使支持,其实现原理也差异很大
3. 这只是列出了一小部分优化技术
4. 以上对比,也可以解释不同数据库对同样语句的行为不同.下面会有一个示例说明

看懂执行计划是DBA优化的前提之一,它为我们开启一扇通往数据库内部的窗口.但是很遗憾,从没有一本书叫做“如何看懂执行计划”,这里的情况非常复杂,很多是需要DBA常年积累而成.

（编辑：ASP站长网）