高性能mysql 第六章查询性能优化 总结(上)查询的执行过程

Posted shenx123

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高性能mysql 第六章查询性能优化 总结(上)查询的执行过程相关的知识,希望对你有一定的参考价值。

6  查询性能优化

6.1为什么查询会变慢

   这里说明了的查询执行周期,从客户端到服务器端,服务器端解析,优化器生成执行计划,执行(可以细分,大体过程可以通过show profile查看),从服务器端返回客户端结果。

   而执行部分作为最重要的一环,需要做的事情比较多,而不合适的query往往让执行过程做了不必要的操作,或者不能使用更优秀的底层数据结构,从而用时更久。

 

6.2慢查询基础:优化数据访问

   访问数据量多大,超过实际所需是慢查询的一个原因。导致这种情况的原因大致有两个

1.应用程序向mysql服务要求的了超过需要的,或重复的数据,比如select * 。

2.mysql服务器执行过程中访问了超过需要的数据。

 

我们先来看第一种原因

6.2.1向数据库请求了超过需要的数据

1.请求了超过需要的行,如没有使用limit,请求了100行数据,但是只使用了10行。

2.使用select * 返回了不需要的列数据,尤其是多表关联查询是情况更突出,应该做的是只返回我们需要的列。

3.客户端如果使用了缓存,并且该部分缓存被接下来的数据需求命中,那么就没有必要再向服务器发送数据请求。

 

6.2.2mysql扫描了额外的纪录

慢查询日志中的三个衡量查询开销的指标:1.响应时间,2。扫描行数,3.返回行数

1.响应时间

响应时间包括服务时间与排队时间。

响应时间在不同的服务器环境,应用环境下都会不同。文中提到使用‘快速上限法’(中文版译名):通过query的执行计划,计算需要的顺序io与随机io次数,再结合当前环境下一次io的时间。最后做一次加总可以获得一个‘参考值‘。(可以看出来,这样的一种方法实操性并不强,因为并不是每一个query我们都能相对准确的估算io次数,不同服务器环境下,甚至统一服务器的不同时间,io的效率也会不同。     不过这里我们可以看出来,io是执行过程中相对比较耗时的一步)

 

2.扫描行数与返回行数

 扫描行数与返回行数单独都是不能体现出任何query的效率的,只有两者的比值才能说明该query筛选数据的能力。

 

3.扫描行数与访问类型

explain 中的type列列出了访问类型:全表扫;索引扫描;范围扫描;单值查询

 

6.3重构查询的方式

 

6.3.1一个复杂的查询还是多个简单的查询

由于mysql的网络协议是‘半双工’的,连接断开的花费并不大,所以很多时候分解查询是优化的sql的一个有效方式。

 

6.3.2切分查询

切分查询是指对大的查询采取分而治之的策略,分时段分但服务器端的压力。但次执行分段的sql都是一样的,只是通过do_query()返回的数据与limit实现对数据条目的分批处理。

 

6.3.3分解关联查询

将关联查询分解成多个sql步骤。

这样做是减小事务的粒度,能够缓解锁的争用,也能让缓存的数据更加模块化,易于使用缓存。

 

6.4查询的执行步骤

客户端请求数据-->服务器端查询缓存,命中返回,未命中-->mysql解析sql,预编译,生成执行计划-->调用数据库引擎api执行sql-->返回结果到客户端

 

6.4.1mysql通信协议

‘半双工’。即同一时间,只有一方在发送数据,只有在接受完对方发送的数据,才可以向对方发出响应。

这里提到了客户端获取数据的两种方式,在c#一种是dateset,即一次性返回数据,在客户端保存数据快照(缓存),一种dateread是保持客户端与服务器端的连接,客户端随时查询数据。--不同的语言提供了不同的调用方式。

 

查询状态

指的是查询的进程的执行状态:需要注意的是sort result对结果集排序;sanding date表示自生成结果集或者在向客户端返回数据。

6.4.2查询缓存

就是查询步骤中的第二步查询的结构。第七章中有介绍。

 

6.4.3查询优化

即是查询步骤中的第三步

 

1.语言解析器与预处理器

解析器对语法进行检查,预处理器检查语义并检查用户是否有权限。

 

2.查询优化器

优化器对预处理器生成的预处理树进行执行计划的测算,计算各种执行计划的花费(有前面的知识我们知道,这里的花费往往指的是查询需要访问的数据页的多少)

可以明白:优化器对成本的测算并不是啊完全准确的,但是对于大多数sqlio都是它的执行瓶颈所在。

注意优化器并不会考虑缓存(有缓存的话不应该第二步就命中,返回给客户端了吗。

 

优化有静态优化与动态优化的区分,考虑到第七章查询缓存部分与存储过程的描述,我在考虑mysql是否保存执行计划呢?如何保存sql的执行计划的呢?静态动态优化时二选一还是并存呢?

 

书中列出了10多中优化器能够优化的查询,我不在一一列举。

 

  1. 数据索引的统计信息

Myisam引擎保存了count,而innodb只能提供估算值(innodb的数据与索引是纠缠的,插入删除修改还可能导致页分裂,页合并等问题,所以保存一个count之类的统计值维护不易)

 

4.关联查询的执行

Mysql的关联查询可以看做一个双循环或者多循环,只有两个表的关联查询,外侧循环的表叫外表,内侧循环的表叫内表。可以知道内侧循环的查询次数是远多于外侧的,所以内表非常需要一个合适的索引。

 

5.关联查询优化器

但是内外表常常不是我们可以决定的,mysql优化器会在其中起作用,优化器会建立一颗深度优先树,通过不同的组合得出花费最少的执行计划。不过在关联的表n过多时执行计划树的颗数会指数上升,n超过optimizer_search_depth就不再使用穷举的方式了,而是使用别的搜索方式获取最优执行计划。

 

上一段中mysql对关联查询的执行方式是嵌套循环,执行计划表现为一颗深度优先树。

 

  1. 排序优化

第三章中介绍了索引排序,这里介绍filesort

Filesort文件排序,filesort并不总是要用到磁盘,当数据量较小时可以再内存中进行。

数据量是否大于文件缓冲区是两者的分水岭。当使用磁盘排序是相当于外排序。

 

Mysql filesort排序策略

两次读取数据(旧版):只使用行指针与排序字段做排序,这样排序结果需要通过行指针才能读取到全部数据,由于是随机ioio效率低。

 

单次读取数据(新版):先读取所需要的列,然后在根据给定列进行排序。

两个各有优劣,这个讨论我们放在第8章中

5.6版本在这里做出了改进,当使用limit时,mysql不再对所有结果排序,而是仅对需要的数据排序。

 

6.4.4查询执行引擎

Mysql的执行计划是一个数据结构,执行该执行计划时,需要调用存储引擎是响应的‘handler api’实现。如果是所有存储过程共有的特性,一般是服务器层实现的,如日期函数,视图,触发器。

 

6.4.5返回数据

Mysql执行sql过程中,开始生成第一条结果时就开始返回数据,这样是的服务器不需要保存大量的结果。(往后看可以发现union会到这个需要新建一个临时表来保存数据,前部union段执行完成才能返回数据)

以上是关于高性能mysql 第六章查询性能优化 总结(上)查询的执行过程的主要内容,如果未能解决你的问题,请参考以下文章

高性能MySQL之第十六章MySQL用户工具总结

MySQL数据操作与查询(第六章 上)

mysql性能优化-自我总结

MySQL---查询性能优化

高性能mysql 4,5,6章优化总结

一份超详细的MySQL高性能优化实战总结!