从页面和任务的真实需求出发

库存列表、批量任务和报表的查询目标并不相同。性能治理可以先回到业务：这次需要哪些字段、查询范围有多大、结果如何分页、关联数据是否真的用得上。把需求边界说清楚，再分析具体 SQL，会更容易找到值得调整的位置。

把一次请求里的查询放在一起看

除了单条 SQL 的耗时，还要检查调用链是否存在 N+1、循环查库或无界查询。列表中的逐行查询可能隐藏在服务方法里；批量任务也可能重复获取相同的数据。整理数据依赖后，用批量查询减少重复访问，并限制一次处理的数据范围。

联合索引与查询结构一起考虑

针对复杂查询，可以结合过滤条件、关联关系与排序方式检查联合索引，同时限定扫描范围、拆分无效关联。索引调整和 SQL 改写需要回到原来的业务场景验证，尤其留意结果集合、数量口径和边界数据是否一致。

一个便于复用的排查顺序

  • 定位具体页面、接口或批量任务。
  • 结合 SQL 与调用链寻找重复查询。
  • 检查扫描范围、关联关系和联合索引。
  • 比较调整前后的结果正确性和执行表现。