由 dawei 数据库搜索慢，常被归咎于SQL写得差，但更多时候是索引“没长对地方”。就像在图书馆里没有分类目录，再快的翻书人也找不到书——索引就是数据库的目录，缺失、冗余或错配都会让查询变成大海捞针。
常见漏洞之一是“全表扫描”。当WHERE条件字段未建索引，或索引列顺序与查询条件不匹配（如复合索引(a,b)却只查b），数据库只能逐行扫描。通过EXPLAIN分析执行计划，若type=ALL或rows远超实际返回量，就亮起红灯。
另一隐患是索引膨胀：为每个字段都建单列索引，不仅浪费存储与写入性能，还会让优化器陷入选择困难，甚至放弃使用任何索引。更高效的做法是合并为覆盖索引——把SELECT字段和WHERE条件涉及的列一并纳入，使查询无需回表，一次定位全部所需数据。
AI渲染图，仅供参考
索引失效还有隐性陷阱：对索引字段使用函数（如WHERE YEAR(create_time)=2023）、隐式类型转换（字符串ID用数字查询）、或LIKE以通配符开头（LIKE ‘%关键词’），都会绕过索引。修复只需调整写法：改用范围查询（create_time BETWEEN ‘2023-01-01’ AND ‘2023-12-31’），统一字段类型，或前置固定字符（LIKE ‘北京%’）。
删除长期不用的索引同样关键。通过performance_schema或慢日志统计，识别近三个月零命中的索引，果断裁撤。每个冗余索引都在拖慢INSERT/UPDATE速度，并增加维护开销。
修复不是一劳永逸。业务迭代后，新增的查询模式可能暴露旧索引盲区。建议将索引健康度纳入发布前检查清单：对高频接口的主SQL做执行计划回归，确保新索引生效且无新增全扫。
索引不是越多越好，而是越准越好。精准的索引像手术刀——切中要害，避开无关组织；持续的优化则如定期体检，让搜索效能始终在线。一次合理的索引调整，往往带来毫秒级延迟下降，而累积起来，就是用户体验的质变。