MySQL索引应精准匹配查询需求，优先为高频、高选择性字段建索引；联合索引须按等值→范围→排序顺序排列；覆盖索引可避免回表但需权衡写入开销；务必用EXPLAIN验证并定期审计慢SQL。
MySQL 索引不是加得越多越好，而是要让 WHERE、JOIN、ORDER BY、GROUP BY 中出现的字段真正被 EXPLAIN 用上——否则就是无效索引，还拖慢写入。
哪些字段适合建索引
核心判断标准：该字段是否频繁出现在查询条件或排序分组中，且选择性（distinct 值 / 总行数）较高。
-
WHERE条件中的等值字段（如user_id = 123）优先建单列索引或作为联合索引最左前缀 - 范围查询字段（
>、BETWEEN、LIKE 'abc%'）只能用在联合索引的最后一位，前面必须是等值字段 -
ORDER BY字段若与WHERE字段组合使用，可合并进同一联合索引（如WHERE status = 1 ORDER BY created_at DESC→ 建(status, created_at)） - 避免对低选择性字段单独建索引，比如
gender（只有 'M'/'F'）、is_deleted（0/1），除非配合其他高选择性字段组成联合索引
联合索引的顺序怎么排
顺序决定索引能否命中——MySQL 只能从左到右匹配，中间断开就失效。
- 等值条件字段放最左（如
tenant_id = 100、app_id = 5） - 多个等值字段按查询频率或区分度从高到低排（区分度高的放更左，利于过滤更多行）
- 范围字段（
>、LIKE 'xxx%'）必须放最后，它右边的字段无法被索引利用 - 示例：
SELECT * FROM orders WHERE app_id = 5 AND tenant_id = 100 AND created_at > '2024-01-01' ORDER BY amount DESC→ 推荐索引(app_id, tenant_id, created_at, amount)，而不是(created_at, app_id, tenant_id)
什么时候需要覆盖索引
当 SELECT 的所有字段都在索引里，MySQL 就不必回表查主键聚簇索引，直接从二级索引取完数据——这对高频只读查询很关键。
- 例如表有
id（主键）、user_id、status、created_at、content，常执行SELECT user_id, status, created_at FROM t WHERE user_id = 123，那么建(user_id, status, created_at)就是覆盖索引 - 注意：
text、blob类型不能包含在索引中；过长的varchar字段建议指定前缀长度（如name(16)），但前缀需保证足够区分 - 覆盖索引会增大索引体积，写入变慢，需权衡读写比例
建完索引一定要验证是否生效
很多索引看似合理，实际执行时根本没走——原因可能是隐式类型转换、函数包裹、字符集不一致，或者优化器认为全表扫描更快。
- 强制用
EXPLAIN FORMAT=TRADITIONAL SELECT ...查看key和rows字段，确认是否命中预期索引 - 警惕这些常见失效场景：
WHERE name LIKE '%abc'（左模糊）、WHERE YEAR(created_at) = 2024（函数操作）、WHERE status + 0 = 1（隐式转换）、WHERE name = 123（字符串字段传数字） - 线上建索引务必用
ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE（MySQL 5.6+），避免锁表；大表建议在低峰期操作，并监控innodb_row_lock_waits
最常被忽略的一点：业务逻辑变更后，旧索引可能已失效，而新查询路径又没补索引。定期用 slow_query_log + pt-query-digest 扫描未走索引的慢 SQL，比凭经验猜更可靠。
