2. SQL 回测概念
2.1 什么是 SQL 回测
SQL 回测（SQL Backtesting）是指在非生产环境（如预发布、灰度或专用回测集群）中，使用真实或模拟的生产流量，对即将上线的 SQL 变更进行全量执行与结果校验的过程。其核心目标是：在不影响线上用户的前提下，验证新 SQL 的正确性、性能与数据一致性。
回测通常包含以下三个关键步骤：
- 流量录制：从生产数据库捕获真实的查询请求、参数与返回结果。
- 回放执行：将录制的流量在目标 SQL 版本上重新执行，并记录执行计划、耗时与结果集。
- 差异比对：对比新版本与基线版本（当前生产版本）的执行结果、性能指标与数据影响。
关键指标：回测通过率通常要求 ≥ 99.9%，且单条 SQL 执行时间偏差不超过基线版本的 ±15%。
2.2 回测与回归测试的区别
很多团队将 SQL 回测与传统的回归测试混为一谈，但两者在目标、范围和执行方式上存在本质差异。下表从六个维度进行对比：
| 对比维度 | SQL 回测 | 回归测试 |
|---|---|---|
| 测试对象 | 单条或批量 SQL 语句 | 整个应用功能模块 |
| 数据来源 | 生产真实流量（录制回放） | 测试人员构造的用例 |
| 执行环境 | 预发布/灰度数据库集群 | 测试环境（通常与生产隔离） |
| 验证重点 | 执行计划、响应时间、结果集一致性 | 业务逻辑正确性、接口返回值 |
| 自动化程度 | 高度自动化（流量录制→回放→比对） | 半自动化（需人工编写用例） |
| 发现缺陷类型 | 性能退化、数据不一致、索引失效 | 功能缺陷、边界条件错误 |
实践建议：SQL 回测不能替代回归测试，两者应形成互补。回测负责数据库层的性能与数据安全，回归测试负责应用层的功能正确性。建议在 CI/CD 流水线中先执行 SQL 回测（耗时短、自动化高），再执行回归测试。
2.3 回测在数据库发布中的核心作用
在数据库变更发布流程中，SQL 回测扮演着 安全阀 和 性能看门狗 的双重角色。以下是其四个核心作用：
- 防止性能退化：通过对比基线执行计划，自动识别因 SQL 改写或索引变更导致的 全表扫描、索引失效 或 Join 顺序错误。
- 保障数据一致性：校验新 SQL 返回的结果集与生产基线是否完全一致，避免因逻辑错误导致 数据丢失 或 重复记录。
- 降低发布风险：在灰度发布前，通过回测暴露潜在问题，避免直接将有缺陷的 SQL 推送到生产环境。
- 提供回滚依据：回测报告中的性能基线可作为发布后的对比基准，一旦出现异常可快速定位并触发回滚。
常见误区：不要认为回测通过就等于 SQL 可以安全上线。回测只能覆盖录制到的流量模式，对于极端边界条件（如超大结果集、并发死锁）仍需结合压力测试和人工审查。建议将回测作为发布流程的 必要非充分条件。
2.4 回测在发布流水线中的位置
一个典型的数据库发布流水线中，SQL 回测通常位于 代码提交后、灰度发布前 的关键节点。以下是一个标准流程：
- 开发提交：开发人员提交 SQL 变更脚本至 Git 仓库。
- 静态检查：自动检查 SQL 语法、规范（如禁止使用 SELECT *）。
- SQL 回测：在回测集群执行流量录制回放，生成差异报告。
- 人工审核：DBA 审查回测报告，确认无性能退化或数据不一致。
- 灰度发布：将 SQL 变更推送到灰度环境（如 5% 流量）。
- 全量发布：灰度观察期（通常 24 小时）无异常后，全量发布。
最佳实践：将 SQL 回测集成到 CI/CD 工具（如 Jenkins、GitLab CI）中，每次提交自动触发。回测失败时阻断流水线，并通知相关开发与 DBA。回测报告应包含执行计划对比图、慢查询列表和结果集差异详情。