最近排查一个 PHP 后台时遇到过这种情况：某个查询接口越来越慢，开发人员第一反应就是给查询字段加索引。索引创建成功以后，接口速度却几乎没有变化，执行时间还是接近原来水平。
继续查看 EXPLAIN 后发现，MySQL 实际上根本没有使用刚加的索引。
这条 SQL 按状态和创建时间筛选数据，同时还需要按照更新时间排序。虽然 status 字段已经单独建立索引，但这个字段只有"待处理、已完成、失败"等几个值，区分度很低。一次查询可能仍然命中几十万条记录，MySQL 判断走索引以后还需要大量回表，最终干脆选择全表扫描。
后来没有继续盲目增加单字段索引，而是根据真实查询条件重新设计联合索引，把高频筛选字段和排序字段按照实际 SQL 组合起来。同时删除一些重复、长期不用的索引，避免写入数据时维护过多索引。
调整以后再次查看执行计划，扫描行数明显下降，接口响应时间也稳定下来。
现在优化 MySQL 查询时，我一般不会把"有索引"和"查询快"直接画等号。索引有没有被使用、字段区分度怎么样、查询条件顺序是否合理、是否还需要额外排序，这些都会影响最终效果。
所以碰到"索引已经加了，SQL 还是慢"，先看执行计划比继续加索引更有效。数据库优化不是索引越多越好，而是让索引真正符合业务查询方式。
#PHP开发 #MySQL优化 #数据库索引 #性能优化