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，比凭经验猜更可靠。
