SQL索引并非越多越好，需在查询频繁、过滤条件明确、数据量大的字段上精准建立；建索引前须查执行计划、算选择率、评估写入代价，按规范流程设计复合索引并验证效果，避开常见误区。
SQL索引不是建得越多越好，关键是在查询频繁、过滤条件明确、数据量大的字段上精准建立——选错字段、忽略数据分布、忽视写入代价，反而会让性能更差。
一、创建索引前必须做的三件事
别急着写 CREATE INDEX，先确认这三点：
- 看执行计划：用 EXPLAIN（MySQL）或 EXPLAIN ANALYZE（PostgreSQL）查慢查询是否真的走不到索引，避免“以为需要，其实已有”
- 查字段选择性：用 COUNT(DISTINCT col) / COUNT(*) 算选择率，低于 5%（如性别、状态位）通常不适合作为单独索引首列
- 评估写入影响：每多一个索引，INSERT/UPDATE/DELETE 就要多维护一份B+树；高并发写场景下，3个以上非必要索引就该警惕
二、标准创建流程（以单表高频查询为例）
按顺序操作，不跳步：
- 定位查询模式：比如常执行 SELECT * FROM orders WHERE user_id = ? AND status = ? ORDER BY created_at DESC
- 设计复合索引顺序：遵循「等值查询 → 最左前缀匹配 → 范围查询 → 排序字段」原则 → 建议索引：(user_id, status, created_at)（注意：status 是等值才放第二位；若常是范围条件，它就得挪到第三位）
-
执行创建（带命名和可选参数）：
CREATE INDEX idx_orders_user_status_time ON orders (user_id, status, created_at); - 验证生效：再次 EXPLAIN，确认 type=ref/range，key 显示索引名，rows 明显减少
三、高频误区与避坑提醒
这些错误，80%的初级开发者都踩过：
- 在TEXT/BLOB字段上直接建普通索引 → MySQL会报错，需指定前缀长度，如 INDEX (content(255))
- 对已存在主键或唯一键的字段重复建索引 → 比如 user_id 是主键，再建 INDEX(user_id) 完全冗余
- ORDER BY 字段没进索引，却指望“索引覆盖排序” → 若索引是 (a,b)，但查询 ORDER BY b，无法避免 filesort
- 上线后从不清理无效索引 → 用 sys.schema_unused_indexes（MySQL 8.0+）或 pg_stat_all_indexes（PG）定期扫描零使用索引
基本上就这些。索引本质是空间换时间的权衡，建之前想清楚读写比、数据特征和真实执行路径，比记住语法重要得多。
