网站管理员在哪里,浙江网站建设而,全景网站建设,网站网页设计心得我们总是希望MySQL能够获得更高的查询性能#xff0c;最好的办法是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点#xff0c;就会发现#xff1a;很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。当向MySQL发送一个请求的…我们总是希望MySQL能够获得更高的查询性能最好的办法是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点就会发现很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。当向MySQL发送一个请求的时候MySQL到底做了些什么呢如下图一、客户端/服务端通信协议MySQL客户端/服务端通信协议是“半双工”的在任一时刻要么是服务器向客户端发送数据要么是客户端向服务器发送数据这两个动作不能同时发生。一旦一端开始发送消息另一端要接收完整个消息才能响应它所以我们无法也无须将一个消息切成小块独立发送也没有办法进行流量控制。客户端用一个单独的数据包将查询请求发送给服务器所以当查询语句很长的时候需要设置max_allowed_packet参数。但是需要注意的是如果查询实在是太大服务端会拒绝接收更多数据并抛出异常。与之相反的是服务器响应给用户的数据通常会很多由多个数据包组成。但是当服务器响应客户端请求时客户端必须完整的接收整个返回结果而不能简单的只取前面几条结果然后让服务器停止发送。因而在实际开发中尽量保持查询简单且只返回必需的数据减小通信间数据包的大小和数量是一个非常好的习惯这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一。二、查询缓存在解析一个查询语句前如果查询缓存是打开的那么MySQL会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存在检查一次用户权限后直接返回缓存中的结果。这种情况下查询不会被解析也不会生成执行计划更不会执行。MySQL将缓存存放在一个引用表(不要理解成table可以认为是类似于HashMap的数据结构)通过一个哈希值索引这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同(例如空格、注释)都会导致缓存不会命中。如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表其查询结果都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间返回不同的查询结果再比如包含CURRENT_USER或者CONNECION_ID()的查询语句会因为不同的用户而返回不同的结果将这样的查询结果缓存起来没有任何的意义。既然是缓存就会失效那查询缓存何时失效呢MySQL的查询缓存系统会跟踪查询中涉及的每个表如果这些表(数据或结构)发生变化那么和这张表相关的所有缓存数据都将失效。正因为如此在任何的写操作时MySQL必须将对应表的所有缓存都设置为失效。如果查询缓存非常大或者碎片很多这个操作就可能带来很大的系统消耗甚至导致系统僵死一会儿。而且查询缓存对系统的额外消耗也不仅仅在写操作读操作也不例外任何的查询语句在开始之前都必须经过检查即使这条SQL语句永远不会命中缓存如果查询结果可以被缓存那么执行完成后会将结果存入缓存也会带来额外的系统消耗基于此我们要知道并不是什么情况下查询缓存都会提高系统性能缓存和失效都会带来额外消耗只有当缓存带来的资源节约大于其本身消耗的资源时才会给系统带来性能提升。但要如何评估打开缓存是否能够带来性能提升是一件非常困难的事情也不在本文讨论的范畴内。如果系统确实存在一些性能问题可以尝试打开查询缓存并在数据库设计上做一些优化比如用多个小表代替一个大表注意不要过度设计批量插入代替循环单条插入合理控制缓存空间大小一般来说其大小设置为几十兆比较合适可以通过SQL_CACHE和SQL_NO_CACHE来控制某个查询语句是否需要进行缓存最后的忠告是不要轻易打开查询缓存特别是写密集型应用可以说是弊大于利全部关闭。可以利用Redis、Memcached当充当缓存。当然查询缓存系统本身是非常复杂的这里讨论的也只是很小的一部分其他更深入的话题比如缓存是如何使用内存的如何控制内存的碎片化事务对查询缓存有何影响等等读者可以自行阅读相关资料这里权当抛砖引玉吧。三、语法解析和预处理MySQL通过关键字将SQL语句进行解析并生成一颗对应的解析树。这个过程解析器主要通过语法规则来验证和解析。比如SQL中是否使用了错误的关键字或者关键字的顺序是否正确等等。预处理则会根据MySQL规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等。四、查询优化经过前面的步骤生成的语法树被认为是合法的了并且由优化器将其转化成查询计划。多数情况下一条查询可以有很多种执行方式最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。MySQL使用基于成本的优化器它尝试预测一个查询使用某种执行计划时的成本并选择其中成本最小的一个。在MySQL可以通过查询当前会话的last_query_cost的值来得到其计算当前查询的成本。mysql show status like last_query_cost;----------------------------| Variable_name   | Value     |----------------------------| Last_query_cost | 16.399000 |----------------------------1 row in set (0.00 sec)这个结果是根据一些列的统计信息计算得来的这些统计信息包括每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的分布情况等等。有非常多的原因会导致MySQL选择错误的执行计划比如统计信息不准确、不会考虑不受其控制的操作成本(用户自定义函数、存储过程)、MySQL认为的最优跟我们想的不一样(我们希望执行时间尽可能短但MySQL值选择它认为成本小的但成本小并不意味着执行时间短)等等。MySQL的查询优化器是一个非常复杂的部件它使用了非常多的优化策略来生成一个最优的执行计划重新定义表的关联顺序(多张表关联查询时并不一定按照SQL中指定的顺序进行但有一些技巧可以指定关联顺序)优化MIN()和MAX()函数(找某列的最小值如果该列有索引只需要查找BTree索引最左端反之则可以找到最大值具体原理见下文)提前终止查询(比如使用Limit时查找到满足数量的结果集后会立即终止查询)优化排序(在老版本MySQL会使用两次传输排序即先读取行指针和需要排序的字段在内存中对其排序然后再根据排序结果去读取数据行而新版本采用的是单次传输排序也就是一次读取所有的数据行然后根据给定的列排序。对于I/O密集型应用效率会高很多)随着MySQL的不断发展优化器使用的优化策略也在不断的进化这里仅仅介绍几个非常常用且容易理解的优化策略其他的优化策略大家自行查阅吧。五、查询执行引擎在完成解析和优化阶段以后MySQL会生成对应的执行计划查询执行引擎根据执行计划给出的指令逐步执行得出结果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来完成这些接口被称为handler API。查询过程中的每一张表由一个handler实例表示。实际上MySQL在查询优化阶段就为每一张表创建了一个handler实例优化器可以根据这些实例的接口来获取表的相关信息包括表的所有列名、索引统计信息等。存储引擎接口提供了非常丰富的功能但其底层仅有几十个接口这些接口像搭积木一样完成了一次查询的大部分操作。六、返回结果给客户端查询执行的最后一个阶段就是将结果返回给客户端。即使查询不到数据MySQL仍然会返回这个查询的相关信息比如改查询影响到的行数以及执行时间等等。如果查询缓存被打开且这个查询可以被缓存MySQL也会将结果存放到缓存中。结果集返回客户端是一个增量且逐步返回的过程。有可能MySQL在生成第一条结果时就开始向客户端逐步返回结果集了。这样服务端就无须存储太多结果而消耗过多内存也可以让客户端第一时间获得返回结果。需要注意的是结果集中的每一行都会以一个满足①中所描述的通信协议的数据包发送再通过TCP协议进行传输在传输过程中可能对MySQL的数据包进行缓存然后批量发送。回头总结一下MySQL整个查询执行过程总的来说分为5个步骤1、客户端向MySQL服务器发送一条查询请求2、服务器首先检查查询缓存如果命中缓存则立刻返回存储在缓存中的结果。否则进入下一阶段3、服务器进行SQL解析、预处理、再由优化器生成对应的执行计划4、MySQL根据执行计划调用存储引擎的API来执行查询5、将结果返回给客户端同时缓存查询结果