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