单列索引和复合索引不是“选一个就好”，而是要根据查询模式、数据分布和写入成本综合权衡。用错索引不仅不加速，还拖慢写入、浪费存储。
优先为高频过滤字段建单列索引
当某个字段经常单独出现在 WHERE 条件中（如 WHERE status = 'active' 或 WHERE user_id = 123），且选择性较好（重复值不多），单列索引就是最直接有效的选择。
- 避免为低选择性字段（如性别、开关状态）盲目建单列索引——优化器很可能不走索引，反而增加维护开销
- 对高基数字段（如手机号、订单号、邮箱）建单列索引效果通常明显
- 注意区分“常用于排序”和“常用于过滤”：仅用于 ORDER BY 但不参与 WHERE 的字段，单列索引收益有限
复合索引要严格遵循“最左前缀原则”
复合索引 (a, b, c) 可以支持 WHERE a = ?、WHERE a = ? AND b = ?、WHERE a = ? AND b = ? AND c = ?，但无法支持 WHERE b = ? 或 WHERE a = ? AND c = ?（缺少 b）。
- 把等值查询字段放前面，范围查询（
>、BETWEEN、LIKE 'abc%'）字段放中间或靠后 - 如果存在
WHERE a = ? AND b > ? ORDER BY c，索引(a, b, c)可同时满足过滤与排序，避免额外排序开销 - 多个查询共用同一张表时，优先合并——比如已有
(user_id, created_at)，新查询是WHERE user_id = ? AND status = ?，可考虑扩展为(user_id, status, created_at)，而非新增单列索引
警惕冗余索引和隐式类型转换
MySQL 和 PostgreSQL 都会因隐式类型转换导致索引失效。例如字段是 VARCHAR，但查询写成 WHERE mobile = 13800138000（传入数字），数据库可能放弃索引做全表扫描。
- 检查
EXPLAIN输出中的 key 和 Extra 列，确认是否真实命中索引 - 用
SHOW INDEX FROM table_name检查是否存在功能重叠的索引，如已有(a, b)，又建了(a)——后者大概率冗余 - 联合索引中字段顺序不合理也会造成“伪冗余”，比如
(b, a)对WHERE a = ?完全无效，但容易被误认为“覆盖了 a”
写多读少场景要控制索引总数
每个索引都会在 INSERT/UPDATE/DELETE 时同步更新。一张表超过 5–6 个索引，写入延迟和锁竞争会显著上升，尤其在高并发事务中。
- 日志类、流水类表（如操作记录、支付明细）优先保证主键和核心查询路径，其他查询尽量走归档或异步聚合
- 用
information_schema.STATISTICS统计各索引的使用频次（MySQL 8.0+ 支持performance_schema.table_io_waits_summary_by_index_usage） - 定期清理长期未被使用的索引，比盲目添加更有效
