维护后台系统时，遇到过一个查询接口响应越来越慢的问题。数据量刚开始只有几万条，接口几乎是秒返回。随着业务持续增加，同样的查询逐渐需要几秒甚至更久，虽然服务器资源没有明显异常，但用户已经能够感受到卡顿。

最初怀疑是SQL写得不够优化，于是把查询语句重新整理了一遍，结果改善并不明显。继续查看执行计划后，才发现数据库没有使用预期的索引，而是直接扫描了整张表。原因并不是缺少索引，而是查询条件组合发生了变化，原来的单字段索引已经无法满足新的业务场景。

后来没有盲目增加多个索引，而是先统计后台最常见的查询方式，再重新设计联合索引。同时删除几项长期没有使用的索引，避免每次新增或修改数据时产生额外维护成本。调整完成后，再次查看执行计划，查询路径已经切换到目标索引，接口响应时间也恢复到比较稳定的状态。

为了避免以后再次出现类似情况，又增加了慢查询日志和执行计划检查步骤。每次新增复杂查询时，不只是验证结果是否正确，也会确认数据库实际使用了哪条索引。如果发现查询条件已经偏离索引设计，就及时调整，而不是等到数据量增长以后再排查。

数据库优化并不是索引越多越好，更重要的是索引是否符合真实业务访问习惯。很多性能问题真正暴露时，代码本身并没有明显错误，而是数据规模变化以后，原来的设计已经不再适合当前场景。定期结合执行计划和慢查询日志一起检查，通常比事后救火更有效。#PHP开发 #MySQL优化 #数据库索引 #性能调优