2025 版 MySQL 索引使用技巧（MySQL 8.0~8.4 实用指南）
到 2025~2026 年，MySQL 主流版本已稳定在 8.0 LTS → 8.4 LTS 过渡阶段。索引优化思路基本稳定，但默认参数、优化器行为和一些微调策略有了细微变化。本文总结目前生产中最实用、最常被问到的索引使用核心技巧，重点标注 8.4 新变化与注意事项。
1. 索引设计核心 12 条铁律（2025 生产共识版）
| 序号 | 规则 | 核心原因 / 收益 | 2025 年特别提醒 / 8.4 变化 |
|---|---|---|---|
| 1 | 区分度越高越靠前（最左列优先） | 区分度 = count(distinct col)/count(*) | 永远放最前面，8.4 优化器更依赖统计信息准确性 |
| 2 | 联合索引字段顺序 = 出现频率 + 区分度 + 等值在前 | 等值 > 范围 > 排序 | 范围列（>、<、between、like ‘xx%’）尽量放后面 |
| 3 | 覆盖索引 > 回表（最重要收益点） | 索引本身包含所有查询字段 → 0 回表 | 优先追求覆盖索引，8.4 对覆盖索引的成本评估更精准 |
| 4 | 单表索引数量控制在 5~8 个 以内 | 每个索引都会增加写开销 + 优化器选择时间 | 大厂规范多为 ≤5 个，超过 8 个几乎必审 |
| 5 | 禁止在低区分度列单独建索引 | 性别、状态、是否删除（0/1）过滤效果极差 | 除非是联合索引的一部分，否则坚决不建 |
| 6 | 尽量避免在索引列上做函数/运算 | 函数破坏索引有序性 → 全表扫描 | 2025 年仍是最常见的失效原因之一 |
| 7 | 范围查询后边的列基本用不到索引 | 最左匹配原则：遇到范围就停止向右匹配 | 8.4 优化器在某些情况下能更好利用范围后的等值（较少见） |
| 8 | LIKE 前缀不要用 % | ‘%xx%’、’xx%’ 才能走索引 | ‘xx%’ 可走，’%xx%’ 和 ‘%xx’ 都不走 |
| 9 | OR 要谨慎（容易退化为全表） | 两边都有索引才可能用到索引合并 | 推荐改写成 UNION ALL 或 IN |
| 10 | 强制索引（USE INDEX / FORCE INDEX）谨慎使用 | 容易过拟合当前数据分布，统计信息变化就失效 | 8.4 优化器更聪明，强制索引使用率应进一步下降 |
| 11 | 冗余索引及时清理 | (a,b)、(a)、(a,c) → (a) 是冗余 | 定期用 pt-duplicate-key-checker 扫描 |
| 12 | 定期执行 ANALYZE TABLE / OPTIMIZE TABLE | 更新统计信息，让优化器做出正确决策 | 8.4 默认统计采样页数增加，统计信息更准，但仍需定期更新 |
2. 联合索引最实用排序规律（背下来就能写 80% 的好索引）
字段出现规律（从高到低优先级）：
WHERE 等值条件（=、IN） → ORDER BY / GROUP BY → 范围条件（>、<、between、like 'xx%'） → 其他经典组合示例（按这个顺序建索引基本不会错）：
-- 最佳实践示例（假设这三个字段都很常用）
CREATE INDEX idx_user_order ON orders (
user_id, -- 最高频等值过滤 + 高区分度
status, -- 次高频等值 + 中等区分度
create_time DESC -- 常见排序字段
);查询命中情况（绿灯=能用索引）：
SELECT * FROM orders WHERE user_id = 123 AND status = 'paid' ORDER BY create_time DESC; → ★★★ 全命中
WHERE user_id = 123 ORDER BY create_time DESC; → ★★ 命中前缀 + 排序
WHERE user_id = 123 AND create_time > '2025-01-01'; → ★★ 前缀 + 范围（status 用不到）
WHERE status = 'paid' ORDER BY create_time DESC; → × 失效（违反最左）3. 2025 年 MySQL 8.4 时代新增/值得关注的索引相关变化
| 变化点 | 说明 | 对索引使用的影响 |
|---|---|---|
| 自适应哈希索引（AHI）默认关闭 | 8.4 默认 off（之前是 on），降低写放大，但某些点查场景可能变慢 | 热点主键查询可能需要手动开启或加普通 B+树索引 |
| innodb_io_capacity 默认从 200 → 10000 | 写性能大幅提升 | 建索引、optimize table 更快 |
| 统计信息采样页数默认增加 | 优化器对数据分布判断更准确 | 索引选择更靠谱，但数据剧烈变化时仍需 ANALYZE |
| Invisible Indexes 更成熟 | 可创建“隐身索引”用于测试，不影响现有查询 | 上线新索引的黄金方式：先隐身 → 观察 → 可见 |
| 全文索引性能继续优化 | ngram / mecab 分词器进一步增强 | 搜索场景可更多考虑原生全文索引 |
4. 推荐的索引评估 & 维护流程（2025 生产标准动作）
- 开启慢查询日志 + long_query_time = 0.5~1s
- 用 pt-query-digest / mysqldumpslow 找出 Top 慢 SQL
- 对 Top 慢 SQL 逐条
EXPLAIN ANALYZE（8.0+ 强烈推荐） - 看 key、rows、Extra（Using filesort / Using temporary 是重点关注对象）
- 根据上面 12 条铁律设计/调整索引
- 上线前用 Invisible Index 先灰度观察
- 上线后 1~2 周观察性能 + 索引使用率（information_schema.statistics）
- 定期（每月/季度）清理冗余索引 + ANALYZE TABLE
5. 一句话总结（2025 版面试/生产金句）
“索引不是越多越好，而是越准越好；覆盖 > 回表 > 扫描行数越少越好；最左匹配 + 高区分度 + 避免函数/类型转换 = 80% 的索引优化精髓。”
把上面 12 条铁律 + 联合索引排序规律背熟，再结合 EXPLAIN ANALYZE 验证，基本能解决 95% 的 MySQL 线上索引相关性能问题。
有具体慢 SQL 或表结构想分析，也可以贴出来，一起看看怎么建最优索引～ 😄
