压测的边界：别把生产库压垮

压测把自己网站压垮的事故，运维圈里隔段时间就会听说一次。压测流量是真实的流量，不会因为你在做"测试"就手下留情。数据库是最常被误伤的一层，因为几乎所有请求的终点都是它。 一、为什么会伤到生产 压测机打向接口，请求最终落到数据库。连接数打满 max_connections 之后，正常业务连不上；压出来的慢查询在库里堆积，锁等待引发连锁反应，同实例的其他业务跟着遭殃。连接打满往往发生在几分钟内，等发现时业务已经在报错。备份、监控采集这些后台任务也会被压测流量挤到超时，故障面比想象的大。更隐蔽的是缓存被压测数据冲掉，压完之后缓存冷启动，真实用户反而变慢。 二、影子库是底线 需要摸容量极限，就用和生产同配置的隔离环境：数据脱敏后克隆一份，压测流量全部指向影子库，随便压到挂也不影响线上。影子库的连接串、域名要与线上隔离，配置文件里单独管理。脱敏不能只改名字，手机号、地址这类字段要整体替换。环境与生产差异有多大，结论就要打多少折扣，这一点要写进报告。 三、限流压测的纪律 确实要在生产上验证，就得设边界：从极低并发起步，逐步加压；定好熔断线，比如错误率超过百分之一或响应超过 500 毫秒立即停止，写进压测方案，执行的人不用临场判断；压测机准备好一键停压的手段，别指望手敲 Ctrl+C 抢时间。有条件的话先在影子库跑同样梯度的压测，拿到预期数字再碰生产。时段选业务低峰，压测前知会值班同事，数据库最好有人盯着 show processlist，异常立即喊停。 四、压完收尾 压测账号用完即禁用，产生的测试数据清理干净，报告归档。 压测的目的是获得数据，不是表演机器的极限，够用的数据量就该收手。