## 症状现象
压测并发从一百升到五百，吞吐一条平线，响应时间却翻着涨。加应用服务器数量，曲线依旧平坦。Web 层看起来毫无压力，问题藏在下游：数据库是大多数网站并发的真实天花板。
## 定位过程
分层压测定位法：先压静态资源，静态页吞吐随并发线性上涨，说明 Web 层无恙；再压读接口，吞吐到某个数字后卡死，响应时间陡增；此时直接连接数、慢查询、锁等待三项数据一查，数据库瓶颈当场现形。数据库侧的典型征象：连接数打满配置上限，新请求排队等连接；少数慢查询占住连接不放，压测时连接池秒空；热点行的锁竞争让并发事务串行化，加并发只是加排队。
show status like 'Threads_connected'; show status like 'Max_used_connections'; show processlist;
应用侧的次要嫌疑也列出来：线程池上限、后端缓存未命中导致全量穿透到数据库、会话串行化。按数据库优先的顺序排查，命中率最高。
## 解决方法
数据库三板斧按序出手：慢查询优化与索引补齐，成本最低收益最大；读写分离把读流量分到副本；热点数据前置缓存，把数据库从每请求一查变成缓存失效才一查。应用侧同步检查连接池配置与超时，连接池上限低于数据库上限时，数据库还有余量应用先饿死。
## 预防建议
容量测试要压到瓶颈现形而不是压到指标达标，平坦的曲线就是瓶颈在说话。顺云云服务器部署的站点，数据库与 Web 分机部署并分别监控，压测报告里两张机器的曲线并排看，瓶颈归属一目了然。
另一个常被忽略的天花板是连接建立的握手成本：高并发短连接场景里，握手与挥手占掉可观的处理能力，长连接复用能把这部分省下来。压测报告建议同时记录连接类型，长短连接的结论不可互相套用。缓存命中率与慢查询数这两个指标做进大盘，数据库瓶颈的苗头在业务变慢之前就会显现。