MySQL 联合索引怎么建：10 道索引失效练习题实测，rows_examined 一样是 8 行，耗时 0.2 ms 和 49 ms

每道题脚本都会先删掉 orders 上全部二级索引，只建本题需要的，再跑 EXPLAIN、EXPLAIN ANALYZE、Handler 计数和 3 次正式执行，耗时取自 performance_schema.events_statements_history_long。下表是复跑结果，完整 34 行答案在样例 CSV 里。

索引 (tenant_id, user_id, created_at)，查询只带 user_id = 4242。按“最左前缀”规则应该用不上，但 SELECT id, created_at 时 EXPLAIN 是 type=range、key_len 6、Extra 里写着 Using index for skip scan，0.2–0.3 ms：tenant_id 只有 20 个值，MySQL 按 tenant_id 的每个值各做一次 (tenant_id, user_id=4242) 的查找，Handler_read_key=41、Handler_read_next=17。

同一个条件改成 SELECT *，需要回表，优化器就不用 skip scan 了，直接全表扫描 200 万行，448–467 ms。最后补一个 (user_id, created_at) 索引，type=ref、key_len 4，0.2–0.3 ms，rows_examined 17。

另一个容易误判的点：skip scan 那次 performance_schema 里 rows_examined 记的是 0，而 Handler 计数显示实际读了 17 条。所以判断走没走索引，以 EXPLAIN 的 type / key / key_len 为准。

还是 (tenant_id, user_id, created_at)，查询 tenant_id = 7 AND created_at 在 2026-09-01 这一天。中间的 user_id 没给条件，created_at 不能参与定位：EXPLAIN 显示 type=ref、key_len 2（tenant_id 是 SMALLINT，2 字节），Extra 是 Using index condition。10.2–11.1 ms，返回 340 行。

key_len 是判断联合索引用到第几列最快的办法：按列类型累加字节数，SMALLINT 2、INT 4、DATETIME 5，可空列再加 1，VARCHAR(n) 按字符集乘以 n 再加 2。这一题如果 created_at 也参与定位，key_len 应该是 2+4+5=11。

给同一条 SQL 加 /*+ NO_ICP(orders) */，EXPLAIN 变成 Using where，耗时 139–242 ms，rows_examined 变成 99535，也就是 tenant_id = 7 的全部索引条目都回表读了一遍。建一个 (tenant_id, created_at) 索引后，key_len 7，type=range，0.7–0.8 ms，只读 340 条。

这是我最想让大家记住的一题。查询是 user_id = 4242 AND created_at >= '2026-03-01' AND created_at < '2026-06-01'，返回 8 行。用 FORCE INDEX 分别强制两个索引：(user_id, created_at) 0.2 ms；(created_at, user_id) 48.4–56.2 ms。两个 EXPLAIN 都是 type=range、key_len 9、Using index condition，表面看不出区别。

我先看了 performance_schema 的 rows_examined：两边都是 8。又看了 Handler_read_next：也都是 8。这两个数字都不算被 ICP 在存储引擎层滤掉的索引条目。给 (created_at, user_id) 那条加上 /*+ NO_ICP(orders) */，rows_examined 和 Handler_read_next 一下变成 673414，耗时 1191–1211 ms，这才是 3 个月范围内的全部索引条目。

原因是 B+ 树按索引列顺序排序：范围列在前时，3 个月内所有用户的条目连在一起，user_id 只能逐条检查；等值列在前时，user_id = 4242 的条目连在一起，再在里面按 created_at 取一小段。两个索引都在、不加 hint 时，优化器选了 (user_id, created_at)，0.2 ms。

索引 (tenant_id, created_at)。tenant_id = 7 ORDER BY created_at DESC LIMIT 20：Backward index scan，0.6–0.7 ms，只读 20 行。改成 tenant_id IN (7, 8)，Extra 变成 Using index condition; Using filesort，372–390 ms，rows_examined 199708：两个租户的数据都读出来，排序后再取 20 行。

值不多时可以改写成 (… WHERE tenant_id = 7 ORDER BY created_at DESC LIMIT 20) UNION ALL (… WHERE tenant_id = 8 …) ORDER BY created_at DESC LIMIT 20，每段各自走索引倒序取 20 行，外层只排 40 行，1.0–1.1 ms。

Q5 是 ORDER BY tenant_id ASC, created_at DESC LIMIT 20。只有 (tenant_id, created_at) 时，方向不一致，只能全索引扫描 + filesort，317–334 ms，rows_examined 2000020。MySQL 8.0 开始支持真正的降序索引，建 (tenant_id, created_at DESC) 后 Extra 只剩 Using index，0.2 ms。

user_id = 4242 OR sku_code = 'SKU01234'：user_id 和 sku_code 各有一个单列索引时，EXPLAIN 是 index_merge、Using union(idx_user, idx_sku)，0.4 ms，68 行。删掉 sku_code 的索引，整条退化为全表扫描，527–547 ms。我顺手试了改写成 UNION，user_id 那半走索引，sku_code 那半照样全表，500–507 ms，改写替代不了缺的索引。

sku_code LIKE 'SKU0123%' 前缀匹配是 range，1.4–1.6 ms；LIKE '%01234' 是全表扫描，579–587 ms。只查 id, sku_code 时会变成扫描整棵 sku_code 索引（Using index），295–299 ms，比全表快一半，但还是扫了 200 万条。真需要后缀搜索，可以另存一列反转后的字符串再建索引，或者用全文检索。

status 只有 4 个值，status = 1 占 60%（1200136 行）。SELECT SUM(amount) WHERE status = 1，优化器估计 992521 行，仍然选了 idx_status，1326–1346 ms；IGNORE INDEX 走全表扫描 292–317 ms。走二级索引要按主键逐行回表，命中行数一多，比顺序扫整张表还慢。换成 status = 9（5%），索引 156–174 ms，全表 272–289 ms，这时候索引才划算。

coupon_code 98% 是 NULL。IS NOT NULL（2%）走 range，65–68 ms；IS NULL 时优化器估计 992521 行，实际 1960238 行，选了 ref 访问，2159–2321 ms，IGNORE INDEX 后 288–293 ms，差 7.6 倍。status NOT IN (1, 2, 3) 被拆成 4 段区间走索引，157–165 ms；status <> 1 优化器估 50% 选了全表，266–268 ms。

所以“NOT IN、<>、IS NULL 不走索引”的说法不准确，能不能走、该不该走，取决于命中比例和统计信息。这类单列索引我一般会先用只读体检 SQL 列出来，再在测试环境用 IGNORE INDEX 对比；确认没用之后，先在 8.0 里把它设为 INVISIBLE 观察一段时间再删。

把 orders 前 20 万行 INSERT … SELECT 到结构相同的新表，每种跑 2 次：只有主键 987–1029 ms；2 个二级索引 1999–2042 ms；6 个二级索引 3671–3816 ms，约 3.7 倍。数据都是 24.6 MB，二级索引分别 0、15.0、39.1 MB。

这里我踩了一个坑：第一版脚本用 CREATE TABLE w0 LIKE orders 建测试表，LIKE 会把源表当时的索引一起复制，而上一题刚给 orders 建了 status 和 coupon_code 两个索引，于是所谓的“0 个二级索引”其实有 2 个，第一次测出来是 1.4 / 2.4 / 4.2 秒，w0 的索引还占了 7.0 MB。看到 0 个二级索引的表有索引大小才发现，下载版脚本已经改成建表前先删光 orders 的二级索引。

练习脚本会建删库，只能在测试实例跑。到自己的库上，我建议先跑这份只读体检 SQL（7 段，只有 SELECT，已过站内只读守卫测试）：版本和 skip_scan / index_merge / ICP 开关；二级索引最多的表；sys.schema_redundant_indexes 里被最左前缀覆盖的冗余索引；sys.schema_unused_indexes 里启动以来没被读过的索引；基数 / 行数 < 0.001 的单列索引；SUM_NO_INDEX_USED > 0 的语句摘要；用了索引但平均超过 10 ms 的语句摘要。

我在练习库上故意建了 idx_user(user_id) 和 idx_u_c(user_id, created_at)、idx_status、idx_coupon 再跑：第 3 段报出 idx_user 被 idx_u_c 覆盖；第 5 段报出 idx_status 基数 3、选择性约 0.0000015；第 6 段把 LIKE '%…'、OR、IGNORE INDEX 的语句按总耗时排在前面。要注意两点：第 4 段依赖实例运行时间，刚重启过的库不能据此删索引；大部分是 NULL 的列（例如本次 coupon_code）基数并不低，第 5 段查不出来，要自己看 IS NULL 的占比。