一、为什么查询速度会慢
1.针对查询真正重要的是响应时间
2.把查询看成一个任务,查询使用的时间就是任务所包含的子任务消耗时间的总和,如果要优化查询,实际上就是减少子任务消耗的时间,或者减少一些子任务,或者减少子任务的执行次数。
二、慢查询基础:优化数据访问
查询性能低下基本原因都是访问的数据太多
1.向数据库请求了不需要的数据
2.扫描了额外的数据
三、重构查询的方式
1.复杂查询分解为简单查询
2.一个大请求分解为多个批次的小请求
3.关联查询分解为单表查询
四、查询执行的基础
执行流程:客户端 => 查询缓存 => 解析器 => 解析树 => 预处理器 => 查询优化器 => 查询执行计划 => 查询执行引擎
1.MySQL客户端/服务器通信协议
2.查询缓存
3.查询优化处理
4.查询执行引擎
5.返回结果给客户端
五、MySQL查询优化器的局限性
1.MySQL的子查询实现的很糟糕
2.UNION的限制
3.等值传递的异常情况
4.MySQL无法做到多核特性来并行执行查询
5.MySQL不支持哈希关联
6.MySQL不支持松散索引扫描
7.MySQL对于Min()和Max()查询的优化也做的并不好
8.MySQL不允许对同一张表同时进行查询和更新
六、查询优化器的提示
1.straight_Join按照SQL指定的顺序进行关联,而不是根据优化器选择的方式进行关联
2.optimizer_search_depth 控制关联优化器是否选择“贪婪”搜索模式
七、优化特定类型的查询
1.count(*)是统计行数
2.InnoDB Explain的行数是一个近似值,但是能提供一个很好的效率
3.关联查询中,关联顺序是第二张表的on或者using字段需要建立索引,而第一张表则不需要
4. Group by没有指定Order by,会自动按照分组的字段排序,如果不需要排序,可以使用order by null,不让Mysql进行文件排序,或者直接在Group by子句中使用Desc或者Asc,按需要的方向排序
5.Union查询,MySQL会默认给临时表加上Distinct选项,如果不需要,需要使用Union All
6.Union和Union All,MySQL都会将结果放入临时表,然后在返回给客户端
7.Explain
Extra = using filesort,order by的字段来自于关联的第一张表
Extra = Using temporary, Using filesort, order by的字段来自于关联的多张表
Extra = Using index for group-by 使用了松散索引
8.SQL_CALC_FOUND_ROWS,代价极高,就算使用了LIMIT,也还是扫描所有的行
备注
1. Explain执行计划的Extra = range checked for each record,是代表在某些关联查询中,范围检查的执行计划会针对每一行重新评估索引。
2.Explain Extended & Show Warnings查看重构SQL查询