数据库CPU飙高
通过top等命令确定是否数据库进程CPU飙高
通过命令show processlist找出耗资源较大的SQL
如果没有特别耗资源的SQL，就查看session是不是突然增多，可以通过限制连接数
如果有特别耗资源的SQL，排查耗资源的SQL是否命中索引、是否表的数据量特别大
kill掉这个消耗大的线程，看看CPU使用率是否下降，调整这条SQL（优化），再手动执行来验证
慢SQL排查
打开慢查询日志开关，设置阈值（默认3s），查看日志，日志会记录慢SQL的语句和执行时间
SQL优化
先要找到需要优化的SQL，查看执行计划（explain），需要重点关注的字段有
type：system > const > eq_ref > ref > range > index > all, 正常情况下，最少要达到range
key：实际命中的索引
possible_keys：可能的索引
rows：估算的读取行数
extra：里面比较重要的有 using index（不需要回表），using index condition（索引下推）
1. 在合适的列上创建索引并能够命中索引，列的值足够离散、列的值不会经常更新、出现在where/order by/group by 后面的列
2. 建立联合索引，尽量实现覆盖索引和索引下推
3. 减少回表次数，比如深度分页的优化
4. 表连接不宜过多，尽量使用inner join代替left join，小表驱动大表
5. 避免使用union，改用union all（不去重）
6. 优先进行过滤， 比如where name like 'kevin%' group by name having age < 18 优化为 where name like 'kevin' and age < 18 group by name
7. 批量进行插入、更新和删除的操作，避免太大
7. 避免其他能让索引失效的情况
8. 尽量降低隔离级别为RC（严格来说不属于sql优化的范围）
9. 避免长事务（严格来说不属于sql优化的范围）
索引不生效的原因
组合索引不满足最左（前缀）匹配原则
以 % 开头的 LIKE 查询
select * （大概率）
在索引列上进行计算、函数、类型转换、隐式转换等操作
where条件使用or、使用is null、is not null
in的取值范围较大
表的数据量很小
标签：索引,where,数据库,排查,SQL,优化,CPU From： https://www.cnblogs.com/huainanyin/p/18136327