17370845950

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