能，但需严格遵循最左前缀原则且状态列不宜置顶；高选择性字段（如user_id）必须放最左，状态列宜居中或靠右，范围查询后字段仅可用于排序或覆盖。
联合索引能加速多状态组合查询吗？
能，但前提是查询条件严格遵循最左前缀原则，且状态列的选择性足够高。直接在 status、type、is_deleted 上堆砌单列索引几乎没用——MySQL 5.7+ 虽支持 index merge，但实际中常因成本估算不准而弃用，反而拖慢查询。
为什么 (status, type, is_deleted) 这个顺序经常失效
因为状态类字段（如 status 只有 'active'/'pending'/'archived'）选择性极低，放在联合索引最左侧会导致 B+ 树分支过宽，过滤效率差。MySQL 优化器可能直接跳过该索引，转而走全表扫描或另一个更“瘦”的索引。
- 优先把高选择性列（如
user_id、category_id、时间范围字段）放在最左 - 状态列适合放在中间或右侧，尤其当它们常和左侧高选择性列一起出现时
- 如果只有状态列参与 WHERE，比如
WHERE status = 'active' AND type = 'order'，那这个联合索引根本不会被用到——缺了最左列
如何验证你的联合索引是否真被用了
别只看 EXPLAIN 输出里的 key 字段非 NULL 就以为万事大吉。重点看 key_len 和 Extra：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
-
key_len值要匹配你预期使用的列数（例如utf8mb4字符串列每字节占 4 字节，VARCHAR(30)最大长度影响计算） -
Extra出现Using where; Using index表示覆盖索引，最快；若只有Using where，说明还得回表查数据 - 执行
EXPLAIN FORMAT=JSON查看used_columns和range_analysis，确认优化器是否真的按你设想的路径走了
真正有效的组合筛选建索引策略
假设常见查询是：SELECT * FROM orders WHERE user_id = ? AND status IN ('paid', 'shipped') AND created_at > ?，那就应该建：CREATE INDEX idx_orders_user_status_time ON orders(user_id, status, created_at);
-
user_id放最左：高选择性，天然分片粒度 -
status放中间：配合user_id进一步缩小范围，IN算范围查询，会让右侧created_at失效——所以把它放最后，只用于排序或小范围裁剪 - 如果查询还带
ORDER BY created_at DESC LIMIT 10，这个索引还能避免文件排序（Using filesort） - 避免在索引列上用函数：
WHERE DATE(created_at) = '2026-11-01'会让整个索引失效
最易被忽略的一点：联合索引不是万能解药。当状态值分布严重倾斜（比如 95% 的记录 status = 'active'），即使索引存在，MySQL 也可能认为走索引比全表扫描更慢——这时得结合分区、物化视图或应用层缓存来解。
