组合索引需按查询模式精准设计，遵循最左前缀原则；冗余索引应识别清理，避免空间浪费与性能下降；建索引前必用EXPLAIN分析执行计划，优先选择小字段、高区分度字段组合。
组合索引不是堆砌字段，而是按查询模式精准设计；冗余索引不光浪费空间，还会拖慢写入和优化器决策。
看执行计划，再建组合索引
别凭感觉加索引。先用 EXPLAIN 或 EXPLAIN ANALYZE 看实际走哪个索引、是否用到索引下推（ICP）、有没有回表。重点观察：
- type 字段是否为 ref、range 或 const（避免 ALL）
- key 是否命中你期望的索引
- Extra 里有没有 Using filesort 或 Using temporary（说明排序/分组没走索引）
比如常查 WHERE status = ? AND create_time > ? ORDER BY update_time DESC，组合索引应为 (status, create_time, update_time)——等值字段在前，范围字段居中，排序字段放最后。
遵循最左前缀，避免字段顺序错位
MySQL 只能从组合索引最左边连续匹配。索引 (a, b, c) 可用于：
WHERE a = 1WHERE a = 1 AND b > 10WHERE a = 1 AND b = 2 AND c IN (3,4)
但无法用于 WHERE b = 2 或 WHERE c = 3（跳过左侧字段）。若还有高频查询 WHERE b = ? AND c = ?，不能复用 (a,b,c)，得单独建 (b,c) ——但要先评估是否真有必要，避免过度索引。
识别并清理冗余索引
冗余 = 功能被另一个索引完全覆盖。例如：
- 已有
INDEX idx_ab (a,b)，又建了INDEX idx_a (a)→ 后者冗余（单列a查询可用idx_ab） - 已有
INDEX idx_abc (a,b,c)，又建了INDEX idx_abd (a,b,d)→ 二者不冗余（c和d不同，用途不同） - 已有
INDEX idx_a (a)和INDEX idx_ab (a,b)→idx_a冗余（除非idx_ab过长导致维护开销过大，需权衡）
用 SELECT * FROM sys.schema_redundant_indexes（MySQL 8.0+）或工具如 pt-duplicate-key-checker 扫描识别。删之前确认无应用依赖该索引（可先 ALTER TABLE ... DROP INDEX 并观察慢日志变化）。
控制索引宽度，优先选小字段+高区分度
组合索引越宽，B+树层级越深、缓存效率越低、写入成本越高。建议：
- 把 等值过滤字段 放前面（如
tenant_id、status），且优先选TINYINT、INT而非VARCHAR(255) - 避免在组合索引里包含大字段（如
TEXT、长VARCHAR），必要时用前缀索引（但注意前缀需有足够区分度） - 对低区分度字段（如
is_deleted TINYINT DEFAULT 0），单独建索引意义不大，放在组合索引靠后位置更合理
比如用户表常用 WHERE org_id = ? AND is_deleted = 0 ORDER BY created_at DESC，索引设为 (org_id, is_deleted, created_at) 比 (is_deleted, org_id, created_at) 更高效——因为 org_id 区分度远高于 is_deleted。
基本上就这些。索引是查询的加速器，不是越多越好；关键在匹配真实查询路径，定期审视，小步迭代。
