单列索引适用于高频独立过滤、高选择性字段，如email、低占比status、时间范围查询；复合索引须遵循最左前缀原则，等值列在前、范围列居中、排序列置后；建索引前必用explain验证，优先复用现有索引前缀，写多读少场景需克制索引数量并定期清理未用索引。
单列索引和复合索引不是“选一个就好”，而是要根据查询模式、数据分布和写入成本综合权衡。用错索引不仅无效，还拖慢插入更新、浪费存储空间。
什么时候该用单列索引？
单列索引适合独立出现在 WHERE、ORDER BY 或 GROUP BY 中的高频过滤字段，尤其是选择性高（重复值少）的列。
- 用户表的
email字段：唯一性强，常用于登录查询，建单列唯一索引能快速定位 - 订单表的
status字段：若常查WHERE status = 'paid'，且该状态占比不到 5%，可考虑单列索引（但需确认是否真的走索引，避免低选择性导致优化器放弃） - 时间字段如
created_at：按时间范围查询（如BETWEEN）频繁时，单列索引通常高效，尤其配合 ORDER BY created_at DESC 分页
复合索引的关键：最左前缀匹配原则
mysql/postgresql 的 B+ 树索引按定义顺序排序存储，查询条件必须从索引最左侧列开始连续匹配，才能有效利用索引。
- 索引
(a, b, c)可支持：WHERE a = ?、WHERE a = ? AND b = ?、WHERE a = ? AND b = ? AND c = ?，以及WHERE a = ? ORDER BY b - 但不支持：
WHERE b = ?、WHERE a = ? AND c = ?（跳过 b）、WHERE b = ? AND c = ? - 等值查询列放前，范围查询（
>、BETWEEN、LIKE 'abc%'）放后，排序字段尽量放在最后——例如查询WHERE tenant_id = 123 AND status = 'done' ORDER BY updated_at DESC，推荐索引(tenant_id, status, updated_at)
别盲目“堆字段”，先看实际执行计划
加索引前，用 EXPLAIN 看查询是否真走索引、是否用到全部索引列、有没有 using filesort / Using temporary。
- 如果
type是ALL或index，说明全表/全索引扫描，可能缺索引或索引没生效 - 如果
key_len明显小于索引总长度（如索引 3 列共 20 字节，key_len=8），说明只用了前几列 - 对已有复合索引，新增单列查询需求时，优先评估是否能复用现有索引前缀，而不是另建单列索引——重复索引会加重写入负担
写多读少场景要克制建索引
每个索引都会在 INSERT/UPDATE/delete 时同步维护。一张表索引越多，写性能下降越明显，尤其高并发写入时。
- 日志类、流水类表（如操作记录、埋点数据），若 90% 是写入、极少查询，通常只在必要字段（如
user_id + created_at联合查）建 1~2 个复合索引即可 - 避免为“以防万一”的模糊查询（如
LIKE '%xxx%'）建索引——B+ 树无法加速前后模糊，这类需求应考虑全文索引或外部搜索引擎 - 定期用
information_schema.STATISTICS或sys.schema_unused_indexes（MySQL 8.0+）识别长期未被使用的索引，及时清理