sql报表性能回归测试核心是验证版本升级后无性能退化，聚焦高频/关键/复杂及历史慢sql，统一基线环境、数据与执行方式，量化响应时间（p95≤+10%）、执行计划稳定性及资源开销，并补充轻量并发与时段回放验证。
SQL报表性能回归测试在版本升级验证中，核心目标是确认新版本未引入性能退化，尤其关注查询响应时间、资源消耗和并发稳定性。重点不是重跑所有报表，而是聚焦高频、关键、复杂SQL及历史慢查询。
明确回归范围：只测该测的
避免全量覆盖，优先锁定三类SQL：
- 业务主报表：日活超500次或管理层每日必看的报表（如销售日报、库存周转看板）
- 历史慢SQL：上一版本中执行时间＞3秒、被DBA标记过或用户投诉过的查询
- 变更关联SQL：本次升级涉及的表结构变更、索引调整、函数改写、统计信息更新所影响的查询
统一测试基线：环境+数据+方法要一致
对比才有意义，必须控制变量：
- 环境配置相同：数据库版本（仅升级目标组件）、CPU/内存规格、磁盘类型（SSD/HDD）、连接池参数保持一致
- 数据规模一致：使用脱敏后等比例生产数据快照（如1:1或1:10），禁用测试库自动采样或空数据集
- 执行方式一致：关闭客户端缓存、清空数据库Buffer Pool（MySQL）或Shared Pool（Oracle），每次执行前执行DBCC DROPCLEANBUFFERS（SQL Server）或ALTER SYSTEM FLUSH SHARED_POOL（Oracle）
量化指标与阈值：别只看“快了没”
用数据说话，设定可接受的波动边界：
- 响应时间：P95延迟变化 ≤ +10%（允许小幅上升），且绝对值不超业务SLA（如≤2s）
- 执行计划稳定性：对比新旧执行计划ID或Hash值，若发生变更，需人工确认是否为优化（如从Nested Loop转Hash Join）或劣化（如索引失效导致全表扫描）
- 资源开销：逻辑读增长 ≤ +15%，TempDB/PGA使用量无突增，无锁等待或死锁新增
补充验证：不能只盯单次查询
真实场景是并发+混合负载，需补两层验证：
- 轻量并发压测：对Top 5报表，模拟5–10用户同时请求，观察平均响应时间、错误率（超时/500）、连接堆积情况
- 时段回归验证：在业务低峰期回放近7天典型SQL调用序列（可用SQL Server Profiler / MySQL Slow Log / Oracle AWR报告提取），检查整体负载趋势是否异常
