#性能调优案例

2019 年，某中型电商公司的订单查询接口平均响应时间是 500ms，p99 延迟超过 2 秒。用户频繁抱怨「下单要等好几秒」，而 DBA 查了一圈数据库后说「数据库没问题」——直到性能团队介入，才发现真正的问题根本不在数据库，而在 ORM 框架的配置里。

性能问题最吊诡的地方在于：问题表象往往指向一个方向，而真正的原因在另一个方向。用户说「页面卡」，你去看前端；前端说「接口慢」，你去看后端；后端说「数据库慢」，DBA 说「数据库没问题」——最后发现，前端渲染没问题、后端逻辑没问题、数据库没问题，但 Redis 连接池太小，每次查询都在等连接。

这一节用四个完整的调优案例，讲解性能问题的识别、诊断和解决思路。

#四类典型性能问题

性能问题的根源通常可以归到四个领域：

#案例关联

四个调优案例不是孤立的，而是按问题的演进逻辑串联：

四个问题相互关联，最终指向一个共同的根本原因：系统的性能问题，往往不是某个组件的问题，而是整个链路上的木桶效应——最短的那块板决定了上限。

#性能优化的核心认知

在做任何优化之前，先记住三句话：

第一句：测量优先于猜测。不要猜「是数据库慢」，不要猜「是 GC 频繁」，先用数据证明问题在哪里。

第二句：优化要追根溯源。加了索引还是慢？可能是 SQL 写错了。改了 SQL 还是慢？可能是 ORM 框架的 N+1 问题。追到真正的根因，优化才能事半功倍。

第三句：最有效的优化往往在架构层。换个算法能提升 10 倍，加个索引能提升 100 倍，而改一下缓存策略能提升 1000 倍。越底层的改动，效果越大，代价也越大。

这四篇文章的每一篇都会遵循这个逻辑：先从真实场景出发，讲清楚问题是什么；再讲诊断过程，找到真正的根因；最后给出解决方案，并分析方案的 trade-off。