10. 性能调优建议怎么表达
性能测试人员通常不是直接负责代码调优的人，但必须能基于测试结果提出合理、可执行的优化建议。面试中问“性能调优建议怎么表达”，重点不是让你变成开发或 DBA，而是看你能不能把瓶颈现象、证据、影响和建议讲清楚，并推动团队复测验证。
性能调优建议不能空泛地写“优化代码、优化数据库、增加服务器”。好的建议应该基于证据：哪里慢、为什么慢、影响是什么、建议怎么改、改完怎么验证。
一、调优建议的表达结构
推荐结构：
现象 -> 证据 -> 判断 -> 建议 -> 复测指标
例如：
500 并发后订单查询响应时间明显升高，95 线达到 3.5s；数据库慢 SQL 显示订单查询未走索引，扫描行数超过 100 万。因此判断瓶颈在订单查询 SQL。建议增加 user_id + create_time 联合索引，并复测 500/800 并发下响应时间和数据库 CPU。
这种表达有证据、有动作、有验证。
二、数据库优化建议
常见建议：
- 增加合适索引；
- 优化 SQL；
- 避免 select *；
- 减少深分页；
- 拆分复杂 join；
- 控制返回数据量；
- 优化排序和分组；
- 调整连接池；
- 读写分离；
- 分库分表。
测试人员提出建议时，要基于慢 SQL、执行计划、连接数、锁等待等证据。
三、缓存优化建议
适合读多写少场景。
建议包括：
- 对热点数据增加缓存；
- 提高缓存命中率；
- 设置合理过期时间；
- 防止缓存穿透；
- 防止缓存击穿；
- 防止缓存雪崩；
- 处理热 key 和大 key。
例如商品详情接口数据库压力高，可以建议热点商品走缓存，但要考虑数据一致性。
四、应用层优化建议
常见应用层问题：
- 代码循环调用数据库；
- 串行调用外部接口；
- 大对象序列化；
- 日志过多；
- 锁粒度过大；
- 线程池配置不合理；
- 连接池配置不足；
- 重复计算。
建议可以是：批量查询、异步化、减少锁范围、调整线程池、减少无效日志、缓存计算结果。
五、架构层优化建议
当单机或单服务达到瓶颈，可以考虑：
- 应用水平扩容；
- 负载均衡；
- 读写分离；
- 服务拆分；
- 异步削峰；
- MQ 解耦；
- 限流；
- 降级；
- 熔断；
- 静态资源 CDN。
架构建议要谨慎，不要一遇到问题就说扩容。扩容不是万能的，数据库瓶颈下盲目扩应用可能更糟。
六、JVM 和系统参数建议
Java 系统可能涉及：
- 调整堆内存；
- 优化 GC 参数；
- 排查 Full GC；
- 调整 Tomcat 线程数；
- 调整连接池大小；
- 调整超时时间；
- 控制日志级别；
- 调整 Linux 文件句柄数。
这类建议要结合监控指标，不要凭空调参数。
七、限流和降级建议
如果系统有明确容量上限，要考虑保护机制。
建议包括：
- 网关限流；
- 接口限流；
- 排队机制；
- 熔断降级；
- 返回友好提示；
- 保护数据库和核心服务。
性能测试不只是让系统更快，也要让系统在高压下不雪崩。
八、复测验证怎么做
调优后必须复测。
复测要对比：
- TPS 是否提升；
- 95 线是否降低；
- 错误率是否下降；
- CPU 是否下降；
- 慢 SQL 是否减少；
- 连接池是否稳定；
- GC 是否改善；
- 是否引入新问题。
没有复测，调优建议就没有闭环。
九、常见错误表达
弱表达：
建议优化数据库。
问题：太空泛。
强表达：
订单查询接口在 800 并发下 95 线达到 4s，慢 SQL 显示按 user_id 和 create_time 查询未命中联合索引，建议增加联合索引并复测。
十、面试回答模板
如果面试官问“性能调优建议怎么表达”，可以这样回答：
我表达性能调优建议时，会基于证据而不是泛泛而谈。一般按现象、证据、判断、建议、复测指标来讲。比如压测时 TPS 到 500 后不再上涨，95 线响应时间明显升高，同时数据库慢 SQL 显示订单查询未走索引，执行计划扫描行数很大，那么我会判断瓶颈在 SQL 和索引，建议增加合适联合索引或优化查询条件，并在相同场景下复测 TPS、95 线、错误率和数据库 CPU。其他优化建议也会按层次区分，比如数据库优化、缓存优化、应用线程池和连接池调整、异步削峰、限流降级或应用扩容，但都要有监控数据支撑。
十一、常见追问
追问：是不是性能差就扩容？
不是。要先定位瓶颈。如果瓶颈在数据库，盲目扩应用可能加重数据库压力。
追问：测试人员能提代码优化建议吗？
可以提出基于证据的方向，比如慢 SQL、锁等待、连接池不足，但具体代码实现由开发评估。
追问：优化后怎么证明有效？
在相同场景和环境下复测，对比 TPS、响应时间、错误率和资源指标。
十二、练习清单
- 写数据库优化建议；
- 写缓存优化建议；
- 写线程池建议；
- 写连接池建议；
- 写限流建议；
- 写扩容建议；
- 写复测指标；
- 对比优化前后结果；
- 避免空泛表达；
- 准备调优建议回答。
性能调优建议的关键是证据链和闭环。测试人员不一定亲自改代码，但要能基于数据提出清晰、可验证的优化方向。
配套刷题：