MySQL索引是数据库中用于快速查找数据的数据结构，常见的索引类型包括B+树索引、哈希索引、全文索引等，其中B+树索引是最常用的类型。合理的索引可以跳过全表扫描，直接定位到目标数据所在的页，大幅减少IO消耗。如果索引设计不合理，不仅无法提升性能，还会增加数据写入和更新的开销。
索引分析的基础方法
使用EXPLAIN查看执行计划
分析索引是否生效最常用的方法是使用EXPLAIN关键字查看SQL语句的执行计划，执行计划会展示查询过程中使用的索引、扫描的行数、查询类型等关键信息。我们可以通过以下语句查看执行计划：
-- 查看查询语句的执行计划 EXPLAIN SELECT * FROM user WHERE age > 18 AND name = '张三';
执行计划返回的结果中，以下几个字段和索引分析密切相关：
- type：查询类型，性能从好到坏依次为system > const > eq_ref > ref > range > index > ALL，其中ALL表示全表扫描，需要优化
- key：实际使用的索引名称，如果为NULL表示没有使用索引
- rows：预估扫描的行数，数值越小说明索引过滤效果越好
- Extra：额外信息，比如Using index表示覆盖索引，Using filesort表示需要额外排序，Using temporary表示使用临时表
查看索引基本信息
我们可以通过SHOW INDEX语句查看表中所有索引的基本信息，包括索引名称、索引包含的列、索引类型、唯一性等：
-- 查看user表的所有索引信息 SHOW INDEX FROM user;
索引优化的常见策略
避免冗余和重复索引
冗余索引指的是一个索引是另一个索引的前缀，比如已经存在联合索引(a,b)，再创建索引(a)就属于冗余索引，因为联合索引(a,b)本身就可以用于a列的单独查询。重复索引指的是在相同列上创建相同类型的多个索引，这种情况会增加写入开销，需要清理。
选择合适的索引列
优先在经常作为查询条件、连接条件、排序条件的列上创建索引，避免在区分度低的列上创建索引，比如性别列只有两个值，创建索引的过滤效果很差。同时要注意索引列不要参与函数计算或者表达式运算，否则索引会失效，比如下面的查询不会使用age列的索引：
-- 索引失效的写法，age参与了运算 SELECT * FROM user WHERE age + 1 = 20; -- 正确的写法 SELECT * FROM user WHERE age = 19;
优化联合索引的顺序
联合索引遵循最左前缀原则，查询条件必须包含联合索引的最左列，索引才会生效。因此创建联合索引时，要把区分度高的列放在前面，把经常单独查询的列放在前面。比如经常有查询WHERE a = ? AND b = ?和WHERE a = ?，那么联合索引(a,b)比(b,a)更合适。
使用覆盖索引减少回表
如果查询的所有列都包含在索引中，那么查询过程不需要回表查询数据行，直接从索引中就可以获取结果，这种索引叫做覆盖索引。覆盖索引可以大幅减少IO消耗，我们可以通过只查询索引包含的列来利用覆盖索引，比如给(name,age)创建联合索引，查询时只查询name和age：
-- 使用覆盖索引，不需要回表 SELECT name, age FROM user WHERE name = '张三';
控制索引数量
索引不是越多越好，每个索引都会占用额外的存储空间，并且在插入、更新、删除数据时需要维护索引，增加写操作的开销。一般单表的索引数量建议控制在5个以内，每个联合索引的列数不要超过5个。
索引优化的注意事项
在进行索引优化时，不要盲目添加索引，需要先通过EXPLAIN分析查询的执行计划，确认索引是否真的能提升性能。同时优化后需要测试查询性能和写操作性能，确保整体性能得到提升。如果表的数据量很小，全表扫描的速度可能比走索引更快，这种情况不需要创建索引。