多列索引到底该不该建？看查询条件是否「成组出现」
直接结论：如果
WHERE子句里经常同时用到 A、B、C 三个字段做等值匹配（比如
WHERE status = 'active' AND user_id = 123 AND created_at > '2025-01-01'），优先建一个
(status, user_id, created_at)多列索引；而不是给每个字段单独建单列索引。
原因很简单：MySQL 一次查询最多只用一个索引。三个单列索引摆在那儿，优化器只能挑一个“区分度最高”的用（比如
user_id），剩下两个字段就得全表扫描或临时过滤——白建了两个。 ✅ 适合建多列索引的典型场景：
SELECT * FROM orders WHERE shop_id = 5 AND status = 'paid' ORDER BY created_at DESC❌ 不适合建多列索引的场景：
WHERE category = 'book' OR author LIKE '%mysql%'（
OR+
LIKE前导通配符，基本无法走索引） ⚠️ 注意：字段顺序不能乱。多列索引
(a,b,c)能加速
WHERE a=1 AND b=2，但对
WHERE b=2 AND c=3完全无效
单列索引不是没用，而是用在「独立高频访问」的字段上
单列索引的价值不在联合查询，而在「单点穿透」：比如用户登录查
username、后台按
deleted_at IS NULL筛有效数据、分页查
id > 1000。
这类操作不依赖其他字段，单列索引就能直达目标行，且占用空间小、维护成本低。盲目替换成多列索引反而浪费资源。
✅ 值得单独建单列索引的字段：id（主键）、
token（API 鉴权）、
state（状态枚举，高区分度） ❌ 别为低区分度字段单独建索引：
gender（只有 'm'/'f'）、
is_deleted（大量重复值），B-Tree 效率极低，还拖慢写入 ? 小技巧：用
SELECT COUNT(DISTINCT col)/COUNT(*) FROM table算区分度，> 0.1 才值得索引
最左前缀原则不是玄学，是 B-Tree 查找路径的硬约束
多列索引本质是一棵按字段顺序排序的 B-Tree。索引
(a,b,c)的叶子节点，先按
a排，
a相同再按
b排，
b也相同才按
c排。所以查询必须从左开始“连续匹配”。
常见失效情况：
WHERE a = 1 AND c = 3→ 只能用上
a，
c无法跳过
b直接定位
WHERE b = 2 AND c = 3→ 完全不走索引（没提供最左列
a）
WHERE a = 1 AND b > 10 AND c = 3→
a和
b有效，
c失效（范围查询后，右侧列索引终止）
验证方法永远是
EXPLAIN，重点看
key和
key_len是否符合预期。
别迷信“全字段覆盖”，小心索引膨胀和更新拖累
多列索引越宽，磁盘占用越大，写入时要维护的索引页越多，
INSERT/UPDATE/DELETE性能下降越明显。尤其当包含大字段（如
TEXT前缀过长）、时间戳、JSON 字段时，代价更高。 ✅ 合理做法：只把真正参与
WHERE/
ORDER BY/
GROUP BY的字段放进多列索引；
SELECT列不用塞进去（除非想实现覆盖索引） ✅ 覆盖索引加分项：如果查询只需返回索引列本身（如
SELECT user_id, status FROM orders WHERE shop_id = 5），可加
INCLUDE（MySQL 8.0+ 支持函数索引或冗余列） ⚠️ 高危操作：为“以防万一”把 5 个字段全塞进一个索引，结果发现
ALTER TABLE卡住 20 分钟，线上写入堆积
真正难的不是建索引，是判断哪些查询模式真实高频、哪些只是开发时随手写的测试 SQL。上线前务必用生产流量抽样分析
slow_log或
performance_schema，别靠猜。
