前言：
从查询设计的一些基本原则开始，介绍一些更深的查询优化技巧，会介绍一些mysql优化器内部的机制；展示MySQL如何执行查询、*也将学会如何改变查询的执行计划，最后看优化器哪些方面做得不够好，探索查询优化模式
目标：帮助大家更深刻理解MySQL如何真正地执行查询，且明白高效低效的原因何在
6.1 为什么查询速度会慢
查询生命周期：
客户端、服务器、服务器解析、生成执行计划、执行（大量为了检索数据到引擎的调用、调用后数据处理：排序 分组等）、返回结果
完成这些任务查询需要在不同地方花费时间:网络 cpu计算 生成统计信息和执行计划 锁等待 等
了解生命周期，清楚查询时间消耗情况对优化查询很大意义
6.2慢查询基础：优化数据访问
almost低下查询可通过减少访问的数据量进行优化
1、确认用于程序是否在检索大量超过需要的数据：访问太多的行/列
2、确认MySQL服务器层是否在分析大量超过需要的数据行
6.2.1是否向库请求了不需要的数据
用缓存、需权衡，尽量不用select * ，limit
6.2.2MySQL是否在扫描额外的记录
指标：1、响应时间，2、扫描的行数，2、返回的行数（到慢日志中找）
响应时间：服务时间+排队时间
服务时间：数据库处理这个查询真正花了多长时间
排队时间：服务器因为等待某些资源而没有真正执行查询的时间
看到一个查询响应时间时，先自问：这个时间是否合理，推荐“快速上限估计”来估算：
了解该查询需要哪些索引及它的执行计划是什么，计算大概需要多少个顺序和随机I/O，用其乘以在具体硬件条件下一次I/O消耗时间，最后相加=大概参考值
扫描的行数、返回的行数
二者应该相同，但是……
explain中的type列反应了访问类型
全表扫描all、范围扫描、唯一索引查询、常数引用：从慢到快、行数从小到大
一般MySQL使用如下三种方式应用where条件，从好到坏：
1、索引中使用where条件过滤不匹配的记录，存储引擎层完成
2、使用索引覆盖扫描（extra列using index）返回记录，直接从索引中过滤不需要的记录并返回命中结果，服务器层，无需回表
3、从表中返回数据，过滤不满足条件的记录（extra列using where）服务器层完成，先从表读出记录然后过滤
优化：
1、使用索引覆盖扫描，all需要的列放到索引中无需回表
2、改变库表结构，单独汇总表
3、重写复杂的查询
6.3重构查询的方式
6.3.1一个复杂查询还是多个简单查询
mysql 连接和断开连接是很轻量级的，响应数据给客户端相比是慢的
其他条件相同时，使用尽可能少的查询是很好的，但是要视情况而定
6.3.2 3切分查询、分解关联查询
大查询：有时候需分而治之
分解关联查询：对每一个表进行单表查询，然后将结果在应用程序中进行关联
1、缓存效率更高：应用程序方便缓存单表查询的结果对象
2、单个查询减少锁的竞争、查询本身效率可能有所提升
3、应用层做关联，更容易对库拆分，易做到高性能和可可扩展
4、减少冗余记录的查询，应用层做关联，对某条记录应用只需查询一次，减少网络和内存消耗
5、相当于在应用中实现了哈希关联，
6.4查询执行的基础
查询执行路径：mysql到底做了什么
6.4.1MySQL客户端/服务器通信协议
半双工：任何时刻，服务器和客户端不能同时给对方放送消息，简单快速但无法控制流量
客户端从服务器获取数据，只能接着不停让其停
多数连接mysql的库函数均可获取all结果集并缓存到内存里（默认）或逐行获取数据
查询状态：
状态：MySQL当前正在做什么，show full processlist （结果集中的command即是）
1、sleep线程等待客户端发送新请求
2、query线程正在执行查询或将结果发送给客户端
3、locked：mysql服务器层，该线程正等待表锁；引擎级别实现的锁：innodb行锁 不会体现在线程状态中
4、analyzing and statistics：线程正在收集存储引擎的统计信息，并生产查询的执行计划
5、copying to tmp table [on disk]线程正在执行查询，且将其结果集都复制到一个临时表中
在做group by 文件排序 union 操作时，后有on disk 表示mysql正在将一个内存临时表放到磁盘上
6、sorting result：线程正在对结果集进行排序
7、sending data：多种情况，可能在多个状态间传送数据，或在生成结果集，或向客户端返回数据
6.4.2查询缓存
是否命中缓存：大小写敏感的哈希查找实现，命中、检查权限（缓存中有）ok返回
小结:
前奏，介绍了一些概念