MySQL索引优化关键在于让索引被正确且高效使用，需遵循最左前缀原则、选择高区分度高频字段、合理设计复合索引，并定期用EXPLAIN验证执行计划。
MySQL索引优化不是“建了索引就变快”，而是让索引真正被用上、且用得高效。很多慢查询问题，根源不在SQL写得差，而在索引没建对、或建了但失效了——比如字段参与计算、顺序错乱、类型隐式转换，都会让EXPLAIN里显示type=ALL（全表扫描）。
为什么WHERE条件写了却没走索引？
最常见原因是违反最左前缀原则。比如你建了复合索引INDEX idx_name_status (name, status)，以下查询能命中索引：
-
WHERE name = '张三'✅（用到最左列） -
WHERE name = '张三' AND status = '1'✅（完整匹配）
但这些不会走该索引：
-
WHERE status = '1'❌（跳过最左列，无法定位） -
WHERE name LIKE '%三' AND status = '1'❌（%开头导致索引失效） -
WHERE name = '张三' OR status = '1'❌（OR常导致索引放弃）
注意：OR不是绝对不走索引，但如果两边字段没都建索引，优化器大概率选全表扫描。
建索引前先看“区分度”和“查询频率”
索引不是越多越好，而是要建在高频过滤 + 高区分度的字段上。比如：
-
user_type ENUM('admin','user','guest')：只有3个值，基数太小，建索引意义不大； -
user_id或email：几乎唯一，区分度高，适合做索引； -
create_time单独建索引效果一般，但和status组合成(status, create_time)就很实用——尤其查“待审核的最近10条记录”这类场景。
可以用这条SQL快速估算区分度：
SELECT COUNT(DISTINCT column_name) / COUNT(*) AS selectivity FROM table_name;
结果越接近1（比如 > 0.3），越值得单独建索引。
什么时候必须用复合索引代替多个单列索引？
当你的查询固定包含多个等值条件，且总是一起出现时，优先建一个复合索引，而不是分别建两个单列索引。
例如业务中反复执行：
SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';
建 INDEX idx_user_status (user_id, status) 比建 INDEX idx_user_id (user_id) + INDEX idx_status (status) 更优，原因有二：
- 避免优化器只能选其一（MySQL通常一次只用一个二级索引），另一个条件得回表后在内存里过滤；
- 复合索引可覆盖查询（如果SELECT字段都在索引里），直接走索引页，不用回表查数据页。
但注意：字段顺序很重要——把区分度更高的放前面（如user_id比status更唯一），否则可能浪费索引空间又降低效率。
真正容易被忽略的点是：索引不是建完就一劳永逸。表数据分布变化（比如某字段从高区分度变成大量重复）、统计信息过期、甚至MySQL版本升级都可能让执行计划突变。定期用EXPLAIN验证关键查询，比盲目加索引管用得多。
