SQL按需建立组合索引_SQL减少冗余索引策略

组合索引需按查询模式精准设计，遵循最左前缀原则；冗余索引应识别清理，避免空间浪费与性能下降；建索引前必用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 = 1
• WHERE a = 1 AND b > 10
• WHERE 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) ——但要先评估是否真有必要，避免过度索引。

识别并清理冗余索引

冗余 = 功能被另一个索引完全覆盖。例如：

Tome

先进的AI智能PPT制作工具

143

查看详情

• 已有 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。

基本上就这些。索引是查询的加速器，不是越多越好；关键在匹配真实查询路径，定期审视，小步迭代。