不会做压力测试不配自称DBA

本期播客

大学生数据库实践课：掌握压测工具pgbench

在数据库的学习旅程中，“性能”永远是绕不开的核心。很多同学代码写得天花乱坠，但一上线就崩，原因就在于缺乏对并发压力的真实预判。

今天这篇文章，我专门为大学生朋友们整理了 PostgreSQL 自带的神兵利器 —— pgbench 的使用实战。不管是应付课程实验，还是未来的工程实践，学会“压测”是你迈向高级开发者的必经之路。

核心要义：为什么你要掌握 pgbench？

数据库性能不是一个静止的数字，而是随并发量、数据规模和 SQL 复杂程度动态变化的。pgbench 让你能模拟成百上千的人同时访问数据库，从而找出系统的吞吐量（TPS） 和延迟瓶颈。

1. 快速上手：标准 TPC-B 测试

如果你只是想快速看看数据库的基本素质，直接用内置的三板斧：

• 初始化 (-i) ：它会自动帮你建好 4 张标准的测试表，记得配合 -s（缩放因子）来控制数据量。
• 执行压测 (-c, -j, -T) ：通过控制并发客户端数和执行时长，观察 TPS。
• 只读/更新模式：利用 -S 或 -N 快速切换测试重点。

2. 深度进阶：自定义业务场景压测

这才是这篇文章的精华。真实的业务（如电商下单）比标准测试复杂得多。我把这套流程归纳为：

• 设计场景：先在脑子里想清楚业务逻辑（查商品 -> 下单 -> 改库存）。
• 环境准备：建表、建索引、造数据。注意，索引好不好，压测一下就知道！
• 脚本编写：利用 pgbench 的 .sql 脚本语法，学会使用 \set 随机变量和 :variable 传参。
• 执行与评估：通过 -f 挂载你的脚本，开启“模拟飞行”。

我给同学们的几个避坑指南：

• 不要“裸奔”测试：测试自定义脚本前，一定要运行 ANALYZE 确保统计信息准确，否则执行计划跑偏，测出的结果没意义。
• 随机数的陷阱：在函数里用 ORDER BY RANDOM() 看起来很方便，但在大数据量下极其耗费 CPU。我建议在脚本中使用 random() 函数配合变量。
• 重视延迟报告：不要只盯着 TPS 看，记得带上 -r 选项。它会告诉你哪一条 SQL 拖了后腿。
• 注意初始化代价：pgbench -i 会删除旧表，操作前确认你的重要数据已经备份。

总结：从“能运行”到“高性能”

通过这篇文章提供的电商系统压测范例，我希望大家不仅学会命令怎么打，更能理解 “监控-分析-调优” 的闭环。数据库不是黑盒，pgbench 就是那一扇透视性能真相的窗户。

延伸作业：试着在你的压测脚本里增加/删除一个索引，看看 -r 报告里的延迟变化，你会对 B-Tree 索引的价值有全新的认识。

详细教程, 点击「阅读原文」