慢查询原因
一条sql偶尔查询很慢
原因
- 数据库更新频繁，redo log buf很快满了，只能先暂停其他操作，将redo log buf同步写到磁盘上时，这时候查询只能等待写磁盘完成了。
- 查询涉及到的表或行被加锁了，只能等待锁被释放。
一条sql一致查询很慢
应该是sql书写有问题了。
原因
- 字段未创建索引
- 索引失效。索引失效有很多原因。
- 数据库选错索引。数据库的统计信息不准确，选错了索引，analyze 表重新统计信息。或者sql里强制使用某个索引。
索引失效的情况
where、group by、order by等条件使用了运算符、函数like '%XX' 或'%XX%'，即不是'XX%'- 两个列的编码不一致，如utf8、uft8mb4
隐式转换：两个列的数据类型不一致。mysql支持字符串转数字，隐式转换，字符型字段 = 数字，会将字符型字段转为数字来比较，字段不是原本的字符型了or有一边的列无索引，即使都有索引，优化器也要根据情况选择是否使用索引联合索引不符合最左原则
慢查询排查
- 开启慢查询日志slow_query_log=1，并设置慢查询时长标准long_query_time
- 查看慢查询日志，使用mysqldumpslow命令，可根据访问次数、返回记录数、查询时间、锁定时间、后三个的平均时间，如平均返回记录数，可根据这些进行排序，指定查看top几，还可以正则匹配。
- 定位到要优化的sql后，explain 慢sql查看执行计划。
explain的结果
id相同的为一组，组内的按出现顺序执行，id越大的组优先执行。
table：查询的表
possible_keys：可能的索引
key：实际使用的索引
rows：mysql估计要扫描的行数
type：显示使用了何种查询，效率从高到低为system>const>eq_ref>ref>range>index>all
system,const mysql能将查询优化成常量，例如
eq_ref：使用了唯一索引。主键索引、唯一索引
ref：非唯一索引
range：使用了between and，>，<，in
index：扫描所有索引行
all：扫描所有数据行，全表扫描
extra：一些额外关键信息。
using index：使用了覆盖索引
using filesort：索引创建数据排序顺序不符合要求，在外部重新排序
using temporary：使用了临时表来保存信息
using where：使用了where
using join buf：关联表未使用索引，且需要缓存来保存中间结果
慢查询需要关注key、rows、type、extra。
慢查询优化
表字段太多
经常不访问的字段，显得多余会影响到查询。可以考虑将经常不访问的字段分离出去，单独成一张表。
表数据量太大
分库分表，水平分表
经常关联的列
将经常关联的列放到一个中间表中，之后不用关联，直接查询中间表效率更高。
关联查询
将关联查询分解为多个小查询，在应用中进行关联。
Limit分页
select name from table1 limit 10000, 5
如果分页按照id排序，可以先查找id后再查询。
select name from table1 where id >= (select id from table1 order by id limit 10000 1) limit 5
如果分页按照某一列排序，在该列创建索引，先查询到该次分页的结果的所有id，再关联查询。
select name from table1 join (select id from table1 order by name limit 10000 5) using id
|