SQL索引需按数据特征、查询模式和原理综合设计；必须建索引的场景包括WHERE高频字段、JOIN关联字段、ORDER BY/GROUP BY字段及覆盖索引字段；联合索引遵循最左前缀原则，区分度高的字段应置左；避免函数操作等导致索引失效。
SQL索引不是“建了就快”，关键在选对字段、用对类型、避开常见陷阱。真正提升查询性能，得从数据特征、查询模式和索引原理三方面一起看。
什么时候必须建索引？
不是所有字段都适合加索引。优先考虑以下场景：
- WHERE 条件中高频出现的字段（如 user_id、status、created_at）
- JOIN 关联字段（如订单表的 user_id 关联用户表主键）
- ORDER BY 或 GROUP BY 的字段（特别是分页查询时，ORDER BY created_at LIMIT 20 很依赖索引）
- SELECT 中的覆盖字段（用 覆盖索引避免回表，比如 CREATE INDEX idx_uid_status ON orders(user_id, status)，查这两个字段就不用碰原表）
单列索引 vs 联合索引，怎么选？
联合索引不是多个单列索引的简单叠加，它有最左前缀匹配规则：
- INDEX (a, b, c) 可以加速：WHERE a=1；WHERE a=1 AND b=2；WHERE a=1 AND b=2 AND c=3
- 但不能加速：WHERE b=2；WHERE c=3；或 WHERE b=2 AND c=3（缺少 a）
- 如果既有 WHERE a=1 ORDER BY b，又有 WHERE a=1 AND b=2，一个 (a,b) 联合索引通常比两个单列索引更省空间、更高效
- 把区分度高、过滤性强的字段放左边（比如 user_id 比 status 更适合作联合索引首列）
这些操作容易让索引“失效”
写了索引，但查询还是慢？很可能是触发了隐式失效：
- 对索引字段做函数操作：WHERE YEAR(created_at) = 2024 → 改成 WHERE created_at >= '2024-01-01' AND created_at
- 使用 !=、NOT IN、LIKE '%abc'（前导通配）会跳过索引
- 隐式类型转换：user_id 是 INT，但写成 WHERE user_id = '123'（字符串），可能放弃索引
- OR 连接不同字段：WHERE a=1 OR b=2，除非 a、b 都有独立索引且优化器选择合并，否则常走全表扫描
实战建议：三步检查索引有效性
别靠猜，用工具验证：
- EXPLAIN SELECT ... 看 type（尽量是 ref/const，别是 ALL）和 key（是否命中预期索引）
- 查 information_schema.STATISTICS 或用 SHOW INDEX FROM table_name 确认索引存在且字段顺序正确
- 观察 slow query log 或监控平台，聚焦执行时间长、扫描行数多的语句，针对性优化
基本上就这些。索引不是越多越好，而是越准越好——理解业务查询逻辑，比背命令重要得多。
