MySQL索引优化步骤总结

在项目使用mysql过程当中，随着系统的运行，发现一些慢查询，在这里总结一下mysql索引优化步骤

1.开发过程优化

开发过程当中对业务表中查询sql分析sql执行计划(尤为是业务流水表)，主要是查看sql执行计划，对sql进行优化。

explain执行计划关键属性

select_type,possible_keys,key,rows

(1) select_type 访问类型

system>const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

system:表只有一行记录（等于系统表）

eq_ref：惟一性索引扫描，对于每一个索引键，表中只有一条记录与之匹配。常见于主键 或 惟一索引扫描。

const:表示经过索引一次就找到了，const用于比较primary key 或者 unique索引。由于只需匹配一行数据，全部很快。若是将主键置于where列表中，mysql就能将该查询转换为一个const

性能最好的是const，最差的是ALL

(2) possible_keys

查询涉及到的字段上存在索引，则该索引将被列出，但不必定被查询实际使用.

(3) key

实际使用的索引，若是为NULL，则没有使用索引(这条很关键)。

(4) rows

根据表统计信息及索引选用状况，大体估算出找到所需的记录所须要读取的行数，越小越好.

2.上线前提交DBA审核（流程）

对于关键系统上线前须要把数据表结构和索引提交DBA审核(防止出现没有索引)。

3.持续优化

部分业务表上线时因为数据量很小不会产生慢查询问题，或者上线后随着业务需求变化，可能会产生慢查询问题。

须要持续优化，能够本身查询sql日志，找出慢查询，关注dba发的慢查询sql(通常力度比较粗，通常只有执行时间，没有执行频次)，

对于执行频次比较多sql慢查询的标准（执行时间）通常会要求更高。

借助自动化运维工具，统计sql执行时间和频率来区分慢查询,好比报表服务执行超过1s为慢查询，而一个执行比较频繁的sql(2C业务)超过50ms就定义为慢查询.