性能调优不是玄学，而是基于数据逐层排查的系统化工程。成熟的调优方法论可以避免"猜着改、改完再看"的低效循环，将问题定位时间从数天缩短到数小时。
现象：某支付系统上线后TPS从预期的8000骤降至4000。排查过程：对比新旧版本GC日志→发现Full GC频率从2次/小时增加到15次/小时→堆内存Dump分析→发现新版本引入了大量短生命周期的大对象→调整年轻代比例（-XX:NewRatio=2）→TPS恢复到7500。教训：性能问题往往不是单点故障，而是配置参数不匹配业务特征。
现象：年终决算日终批量任务从预计6小时延长到12小时。排查过程：分析慢查询日志→发现多张大表的全表扫描（未走索引）→检查执行计划→发现统计信息过旧导致优化器选错索引→更新统计信息+添加Hint强制索引→批处理时间恢复到5.5小时。教训：大版本上线前必须更新数据库统计信息。
现象：网银系统P99登录耗时5秒，但平均耗时仅300ms。排查过程：对比P99请求和普通请求的调用链→发现P99请求都触发了密码错误重试→错误重试走的是另一个数据库从库（跨机房）→RTT 15ms×3次重试=45ms网络延迟→但实际瓶颈是连接池在错误路径上未配置超时→设置loginTimeout=3s→P99降到2秒。教训：长尾延迟的根因往往不在热路径上，需要逐笔分析异常请求。
Google SRE推荐的监控导向方法：先看QPS（Rate）是否达到目标→看错误率（Errors）是否在阈值内→看响应时间（Duration）分位数分布。三个指标任意一个异常，就进入USE方法深入排查。
资源导向的瓶颈分析方法：检查每种资源的使用率（是否接近100%）、饱和度（是否有排队等待）、错误数（是否有异常）。按CPU→内存→磁盘IO→网络→数据库→应用层逐层排查。