SQL优化思路

在开发阶段，往往重视的是功能是否实现，是否满足需求，但是却忽略到性能问题，导致线上运行后问题百出，SQL的问题也会凸显出来，成为整个系统的运行瓶颈。

1、通过慢查询日志定位执行效率较低的SQL
2、explain分析SQL的执行计划，重点关注type、rows、filtered、extra
type由上到下，效率越来越高

ALL全表扫描
index索引全扫描
range索引范围扫描，<,<=,>,>=,between,in等操作
ref使用非唯一索引扫描或唯一索引前缀扫描，返回单条记录，常出现在关联查询中
eq_ref类似ref,区别是使用的唯一索引，使用主键的关联查询
const/system单条记录，系统会把匹配行中的其他列作为常数处理，如主键或唯一索引查询
null,Mysql不访问任何表或索引，直接返回结果

Extra

Using filesort：MySQL需要额外的一次传递，以找出如何按排序顺序检索行
Using temporary：使用了临时表保存中间结果，性能特别差，需要重点优化
Using index：表示相应的Select操作中使用了覆盖索引，避免访问了表的数据行，效率不错。如果同时出现了Using where,意味着无法直接通过索引查找来查询到符合条件的数据
Using index condition：MySQL5.6后新增的ICP，在存储引擎进行过滤，而不是在服务层过滤，利用索引的数据减少回表的数据

3、show profile分析
了解SQL执行的线程的状态及消耗的时间，默认是关闭的，开启语句是set profile = 1

4、trace分析优化器如何选择执行计划

5、确定问题并采用相应的措施

优化索引
优化SQL语句：修改SQL、IN查询分段、时间查询分段、基于上一次数据过滤
改用其他实现方式：ES、数仓
数据碎片处理

场景分析

1、索引最左匹配原则，当联合索引（A，B），查询时没用到A，而用B，那么无法使用到索引。可以将索引顺序改变为（B,A）或者查询条件中也用到A

2、隐式转换，相当于在索引上做运算，例如字段是字符类型，但是却使用了数字，应该使用字符串匹配，否则MySQL会用到隐式转换，导致索引失效

3、大分页采用延迟关联的方式，减少SQL回表，但是索引需要完全覆盖才有效果
select t1.* from _t t1, (select id from _t where a = 1 and b = 2 order by c desc limit 10000, 10) t2 where t1.id = t2.id;

4、in + order by
in查询在MySQL底层是通过n*m的方式去搜索，类似union，但是效率比union高

5、不包含、不等于不能用到索引的快速搜索（可以用到ICP）
在索引上，避免使用NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等

6、优化器选择不使用索引的情况
如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚集索引来查找数据。

7、asc和desc混用
select * from _t where a=1 order by b desc, c asc
desc 和asc混用时会导致索引失效

8、数据碎片处理
随着时间推移，基于数据库的应用系统的广泛使用，数据表的增删改总是避免不了产生碎片的问题，产生的碎片会越来越多，导致系统性能减弱、浪费大量的表空间。