一条SQL语句的执行过程以及查询性能的优化

一、MySql一条查询语句的执行过程：

1. 客户端发送一条查询给服务器；
2. 服务器西安检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果，否则进入下一个阶段；
3. 服务器端进行SQL解析，预处理（预处理器），再有优化器生成对应的执行计划；
4. MySQL根据优化器生成的执行计划，调用存储引擎的API来进行查询；
5. 将结果返回给客户端

二、查询速度慢原因：

一条ＳＱＬ语句执行的快慢最重要的衡量标准就是响应时间，如果把成查询当作是一个任务，那么它由一系列子任务组成，每个子任务都会消耗一定的时间。如果优化查询，实际上就是优化其子任务，要么消除其中一些子任务，要么减少子任务的执行次数。

（１）优化数据访问–查询性能低下最根本的原因是访问的数据太多。某些查询可能不可避免的需要筛选大量数据，但这并不常见，大部分性能低下的查询都可以通过减少访问的数据量的方式进行优化。对于低效的查询，通过下面两个步骤来分析总是很有效：

• 确认应用程序是否建索大量超过需要的数据。这通常意味着访问太多的行，有时候也可能是太多的列；

• 确认ＭｙＳＱＬ服务器层是否建索大量超过需要的数据行。

（２）是否向数据库请求了不需要的数据–有写查询会请求超过实际需要的数据，然后这些多余的数据就会被应用程序丢弃，这会给MySQL服务器带来额外的负担，并增加网络开销，另外也会消耗应用服务器的CPU和内存资源，例如：

• 查询不需要的数据，（一下取出大量的结果，然后获取前N行后关闭结果集，这样就抛弃了大部分数据，最有效的解决方法就是在这样的查询后面加Limit）

• 多表关联时返回全部列（）

• 总是取出全部列（例如一些Select * 的查询，要做好审视，是不是真的需要返回所有的列，很可能不是必须的。去除所有列，会让优化器无法完成索引覆盖扫描这类优化，还会为服务器带来额外的IO，内存和CPU的消耗）

• 重复查询相同的数据（好的解决方法是，当初查询的时候将这个数据缓
  存起来，需要的时候从缓存中取出，这样性能显然会更好）

（3）MySQL是否在扫描额外的记录–在确查询只返回需要的数据之后，接下来应该看看查询为了返回结果是否扫描了过多的数据，最简单的很亮查询开销的三个指标如下：

• 响应时间
• 扫描的行数
• 返回的行数

这三个指标都会记录到MySQL的慢日志中，所以检查日志记录是找到扫描行数过多的查询的好办法。
优化查询的方式有多种，今天我们先讲一下其中的一种，那就是
重构查询的方式：有切分查询、分解关联查询。

• 切分查询
  运用中删除旧的数据是一个很好的例子。定期的清除大量的数据，如果用一个大的语句一次行完成的话，则可能需要一次所著很多数据，占满整个事务日志，耗尽系统资源、阻塞很多小的但重要的查询。将一个大的Delete语句切分成多个较小的查询可以尽可能小的影响MySQL的性能，同时还可以减少MySQL复制的延迟；例如一个月进行一次的查询：

 mysql> DELETE FROM msg WHERE created < DATE_SUB(NOW(), INTERVAL 3 MONTH);

可以用以下办法完成相同的工作：

rows_affected=0
do{
	row_affected = do_query(
		"DELETE FROM msg WHERE created < DATE_SUB(NOW(), INTERVAL 3 MONTH)
		 LIMIT 10000")
} while rows_affected >0