内容摘要：我见过太多系统在压力测试面前原形毕露。SQL Server 数据库尤其如此——平时查询飞快，一旦并发冲到几百，锁等待、死锁、磁盘队列全部冒出来。今年三月，我们给一个电商平台做压测，订单表才两千万行，每

我见过太多系统在压力测试面前原形毕露。数据试SQL Server 数据库尤其如此——平时查询飞快，库压一旦并发冲到几百，力测锁等待、数据试死锁、库压磁盘队列全部冒出来。力测今年三月，数据试我们给一个电商平台做压测，库压订单表才两千万行，力测每秒写入五百笔就撑不住了，数据试日志文件疯狂膨胀，库压最后直接卡死。力测问题不在硬件，数据试而在索引碎片和隐式转换。库压

压力测试的力测核心就一句话：找到那个压垮系统的临界点。别指望生产环境出问题再去救火，那代价太高。我习惯先建一个跟生产环境结构一致的测试库，用真实数据量填充——注意，抽样数据没用，统计信息失真会让执行计划跑偏。然后开跑，监控几个关键计数器：CPU占用率、等待类型、锁等待时间、日志增长速率。

最容易被忽略的是等待类型。很多人只看CPU和内存，其实SQL Server的等待统计才是诊断金矿。比如PAGEIOLATCH_SH说明磁盘读太慢，LCK_M_X说明锁竞争严重，WRITELOG说明日志写入瓶颈。我见过一个案例，压测时CPU才30%，但请求全部卡住，一看等待类型全是ASYNC_NETWORK_IO——应用端逐行读取结果集，数据库被迫等客户端慢慢消费。这种问题加硬件没用，得改代码。

压测工具我推荐开源的Sysbench配合自定义脚本，或者直接用SQL Server自带的osql循环。别迷信商业工具，很多时候一个简单的PowerShell脚本就能模拟出足够真实的并发场景。关键是并发模型要贴近实际——不是所有请求都平均分布，往往80%的流量集中在几个热点查询上。你得先分析生产环境的实际请求模式，再设计压测脚本。

还有一点，压测不能只看吞吐量。响应时间分布比平均值重要得多。平均值90毫秒看着不错，但可能99分位已经飙到三秒。用户体验感知的是最慢的那批请求，不是平均值。我习惯把压测结果按百分位画成曲线，如果P99开始陡增，说明系统已经进入过载区。

测试过程中要逐步加压，不是一上来就全速跑。比如先50并发跑五分钟，观察性能计数器稳定后，再升到100、200。每档之间留出观察窗口，记录系统在每档的表现。当你发现响应时间开始非线性增长，或者锁等待次数突然翻倍，那就是临界点附近了。

压测结束后，别急着收工。看下SQL Server的DMV，找出那些累计消耗最高的查询——通常就是压测暴露出来的罪魁祸首。我上次压测完，发现有个查询逻辑读高达几十万次，就因为在WHERE子句里对索引列用了函数。改写后，逻辑读降到几百，性能提升了近百倍。这才是压测的价值：不只是测出系统上限，更是找出拖后腿的具体SQL。

最后提醒一句，压力测试要定期做。数据库数据量在涨，索引在变碎，统计信息会过期，应用代码也在迭代。三个月前测出来的结论，今天可能就不适用了。我见过太多团队上线前才临时抱佛脚压测，结果发现问题已经来不及改。把压测集成到CI/CD流程里，每次发布前自动跑一轮基础场景，比什么都管用。