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或
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验证关键查询，比盲目加索引管用得多。
