从日志入手定位系统性能瓶颈

系统变慢时，最容易走弯路的是「先猜原因、再改代码」。更可靠的做法是从日志和监控出发，按固定顺序收敛排查范围。

第一步：先把现象量化

不要接受「系统很慢」这样模糊的描述，先问清三件事：

• 慢的是哪个功能，而不是整个系统
• 从什么时候开始，之前有没有发版或数据量突增
• 是持续慢还是偶发慢，两者排查方向完全不同

第二步：先看日志，不要先看代码

把同一时间窗口的应用日志、慢查询日志与系统负载按时间轴对齐，通常能立刻看出特征：

• 错误日志突增并伴随变慢 → 下游依赖异常，重试放大了压力
• 慢查询集中出现 → 索引缺失，或数据量跨过了临界点
• 没有明显异常但吞吐下降 → 线程池耗尽或连接池等待

第三步：慢查询的收益最高

绝大多数业务系统的瓶颈最终落在数据库上。先看执行计划，重点确认：

• 有没有走索引，还是在做全表扫描
• 排序、分组是否产生了临时表
• 返回行数是否远超实际需要的行数

经验：加一个合适的联合索引，往往比改十处业务代码更有效。

第四步：必须复测

改完要用同一份脚本复测同一组指标。没有复测的优化只是改了代码，并不代表问题已经解决。