mysql查询过程：
- 客户端发送查询请求。
- 服务器检查查询缓存，如果命中缓存，则返回结果，否则，继续执行。
- 服务器进行sql解析，预处理，再由优化器生成执行计划。
- Mysql调用存储引擎API执行优化器生成的执行计划进行查询。
- 返回结果。
优化数据访问：
- 只获取必要的数据：
- 是否查询了多余的记录；
- 多表关联时是否返回了全部列；
- 是否总是取出全部列（避免select *）；
- 是否重复查询相同的数据（缓存代替）。
- 避免额外的记录扫描：查询开销衡量标准（响应时间、扫描行数、返回行数）
- 响应时间：服务时间（执行查询）+排队时间（IO或者等待资源、锁等）；快速上线估计法。
- 扫描的行数和返回的行数：一般1:1-->1:10。
- 扫描行数和访问类型：同一行数据的不同访问方式（扫描表、索引、范围访问、唯一索引、常熟引用、单值访问）的扫描行数的差异，通常增加索引是一个最直接的方法。大量扫描返回少量行数的查询优化技巧：
- 使用索引覆盖扫描：把所有需要的列放到索引中，存储引擎无需回表获取对应的行，直接返回结果。
- 改变库表结构：增加汇总性表存储，空间换时间，效率。
- 重写查询：sql结构。
重构查询方式：
- 复杂查询与简单查询的选择：复杂查询考虑的是网络通信，查询解析及优化的因素。将复杂查询分解为多个组合的简单查询有时会是不错的选择。
- 切分查询：将大查询切分为多个相同的小查询。例如：删除旧数据时。
- 分解关联查询：将分解的单个查询在应用层进行整合。
- 增加缓存效率：应用服务通常需要缓存常用单表查询，重复利用。
- 分解的单个查询可以减少锁的竞争。
- 应用层进行关联，使得数据库拆分更加容易，构建高性能及高扩展性的程序、服务。
- 查询效率的提升。
- 减少冗余记录的查询。
- 应用层的哈希关联效率高于mysql的循环嵌套关联。
特殊优化：
- count(*) 并不是统计所有列，而是是统计行数。
- MyISAM的count()在没有where条件的时非常快，优于其它引擎。
- 快速、精确、实现简单 只能满足其二。
- 优化关联查询：
- 确保ON或者USING子句中的列上有索引。在创建索引时要考虑关联的顺序，一般来说，除非有其它理由，否则只需要在管理按顺序中的第二表的相应列上创建索引。
- 确保任何的GROUP BY和ORDER BY中的表达式只涉及到一个表中的列，这样Mysql才能使用索引来优化过程。
- 升级Mysql需要检查优化。
- 5.6之前尽可能使用关联查询代替子查询。
- UNION查询：Mysql通过创建填充临时表的方式来执行。