压测目标是验证SQL报表在真实业务负载下的稳定性与响应能力，需明确并发用户数、P95响应时间≤3s、数据库资源上限及错误率阈值，并据CPU高、IO等待高等指标定位解析争用或SQL逻辑读问题。
明确压测目标与关键指标
压测不是盲目加压，核心是验证SQL报表在真实业务负载下的稳定性与响应能力。需提前定义清楚：支撑多少并发用户、平均/最大响应时间容忍值（如P95 ≤ 3s）、数据库CPU/内存/连接数上限、错误率阈值（如
构建贴近生产的数据与查询场景
用空库或小量测试数据压测，结果毫无参考价值。必须做到两点：
- 数据规模匹配：按生产表行数1:1或按比例缩放（如10%），尤其关注大宽表、历史分区表、索引字段分布；
- 查询行为仿真：从实际慢日志或APM中提取Top N报表SQL，保留参数动态性（如日期范围、机构ID），避免固化值导致执行计划缓存失真。
分阶段递增施压并实时监控
采用“阶梯式+峰值维持”模式，例如：50 → 100 → 200 → 300 并发，每档持续5分钟，再冲高至350并发维持10分钟。过程中同步采集：
- 应用层：QPS、平均RT、超时数、线程池堆积量；
- 数据库层：活跃会话、等待事件（重点关注 latch: shared pool、enq: TX - row lock contention、db file scattered read）；
- 系统层：CPU使用率、Buffer Hit Ratio、PGA/SGA命中率、磁盘IO吞吐与延迟。
定位瓶颈的典型路径
当响应时间陡升或错误激增时，按以下顺序快速收敛根因：
- 查看数据库等待事件：若大量 cursor: pin S wait on X，指向硬解析过多，检查绑定变量缺失或shared_pool过小；
- 检查执行计划是否变更：同一SQL在压测中突然走全表扫描，可能是统计信息过期或绑定变量窥探失效；
- 观察锁等待：出现 enq: TM - contention 或长时间 TX 等待，说明存在DML与报表查询的阻塞冲突；
- 核对资源饱和点：CPU持续 > 90% 且 %sys 高，可能为频繁解析、Latch争用或不当并行；IO await > 20ms 且 read/write IOPS逼近磁盘极限，需优化SQL减少逻辑读或调整存储。
