在 PostgreSQL 开发中，优化器更新或 schema 变更常常导致查询计划意外变化，从而引发性能回归。这种问题在生产环境中特别棘手，因为它可能悄无声息地将毫秒级查询转为秒级操作，甚至引入错误结果。观点上，建立自动化回归测试套件是维护数据库稳定性的关键，它不仅验证查询正确性，还监控执行计划和性能指标，确保变更不会破坏现有行为。
证据显示，PostgreSQL 自身的回归测试框架已证明有效，该框架通过比较预期结果和计划来防范核心开发中的灾难。RegreSQL 工具将这一方法扩展到应用查询层面，支持结果基线比较和性能跟踪。例如，在 Chinook 数据库示例中，RegreSQL 运行查询后检查 JSON 输出是否匹配基线，同时评估成本是否超过 110% 阈值（默认 10% 容差）。它还能检测不良计划模式，如顺序扫描（sequential scan）或嵌套循环与顺序扫描结合，这些往往表示缺少索引或优化不当。在一个测试输出中，多个查询被标记为有顺序扫描警告，建议添加索引以避免在大型表上的低效执行。
要落地这一测试套件，首先安装 RegreSQL（从 GitHub https://github.com/boringSQL/regresql 获取）。配置 PostgreSQL 连接字符串，如 postgres://user:pass@host/db。准备 SQL 文件，每个查询用 -- name: query_name 标记，支持 :varname 占位符。运行 regresql baseline 生成基线文件，存储在 regresql/baselines 目录下，包括 .json（结果）和 .cost（性能）。
测试数据管理至关重要，使用 YAML 夹具（fixtures）确保可重现性。在 regresql/fixtures/ 目录创建文件，如 basic_users.yaml：
fixture: basic_users
description: 测试用户数据
cleanup: rollback
data:
-
table: users
rows:
-
id: 1
email: alice@example.com
name: Alice Anderson
-
对于大规模数据，使用生成器：
fixture: realistic_orders
generate:
-
table: customers
count: 1000
columns:
id:
generator: sequence start: 1email:
generator: email domain: example.com
运行 regresql test 执行测试，输出包括通过 / 失败计数和警告。针对性能回归，监控成本变化：如果成本超过基线 * 1.1，测试失败。查询元数据允许自定义，如 -- regresql: noseqscanwarn 禁用顺序扫描警告，或 difffloattolerance:0.25 设置 25% 容差。
集成到 CI/CD：使用 jUnit 或 JSON 输出格式，如 regresql test --format junit > results.xml，便于 GitHub Actions 或 Jenkins 解析。监控要点包括：每周运行全套测试，变更后立即验证；设置阈值警报，如成本增加 >20% 时通知团队。对于 ORM 生成 SQL，使用事件钩子捕获语句并保存为 .sql 文件测试。
回滚策略：如果测试失败，检查计划差异（使用 EXPLAIN ANALYZE），添加 / 移除索引，或调整统计信息（ANALYZE 表）。清单：
-
安装 RegreSQL 并配置连接。
-
编写 / 捕获 SQL 查询文件。
-
定义 YAML 夹具和计划文件（regresql/plans/*.yaml）。
-
生成基线：regresql baseline。
-
运行测试：regresql test，审查警告。
-
集成 CI：添加脚本到 pipeline。
-
维护：更新夹具以匹配 schema 变更，调整容差基于负载。
这种方法将查询测试从手动验证转为自动化流程，显著降低生产风险。实际参数如默认 10% 容差可根据查询类型调整：高频查询用 5%，批量用 20%。通过计划比较，确保优化器变更不引入回归，最终提升系统可靠性。
资料来源：boringSQL 博客（https://boringsql.com/posts/regresql-testing-queries/），RegreSQL GitHub 仓库。