压测需围绕业务关键路径设定可量化目标，如订单查询接口在500 qps下响应时间≤200ms、错误率≤1%；若物理读频繁则需扩容或优化热点访问；优化后须回归原场景验证指标达标且无副作用。
明确压测目标与基准场景
压测不是盲目加压，而是围绕业务关键路径设计可量化的验证目标。例如：核心订单查询接口在 500 QPS 下平均响应时间 ≤200ms，错误率
构造贴近真实的压测数据与流量
避免使用全随机或固定值数据，否则无法暴露索引失效、统计信息偏差、锁竞争等问题。建议：
- 按业务比例生成倾斜数据（如 80% 订单集中在最近 7 天，用户 ID 分布符合幂律）
- 复用脱敏后的线上流量特征（如请求参数分布、并发节奏、读写比例）
- 使用工具如 sysbench（定制 Lua 脚本）、JMeter + JDBC Sampler 或 go-sql-driver 压测框架 模拟多线程混合读写
分层监控，快速定位瓶颈环节
单看 SQL 执行时间容易误判。需同步采集三层指标：
- 应用层：JDBC 执行耗时、连接获取等待时间、是否发生连接池耗尽
- 数据库层：SQL 执行计划（EXPLAIN ANALYZE）、锁等待（show engine innodb status）、InnoDB 行锁/表锁争用、临时表使用量、Sort_merge_passes
- 系统层：磁盘 I/O 等待（iostat -x 1）、内存页换入换出（vmstat）、CPU 软中断（sar -n DEV）
典型线索举例：若应用侧耗时飙升但数据库 show processlist 显示 SQL 执行很快，大概率是连接池打满或网络延迟；若执行计划显示 type=ALL 且 rows 扫描量突增，说明索引未生效或统计信息过期。
针对性优化与闭环验证
根据监控证据做最小化干预，每次只改一个变量，并重新压测验证效果：
- 索引问题 → 添加联合索引或调整索引顺序，注意覆盖查询字段
- 执行计划劣化 → 分析是否因数据分布变化导致优化器选错，可用 optimizer_hint 或 ANALYZE TABLE 更新统计信息
- 锁冲突严重 → 检查事务粒度（是否大事务未拆分）、隔离级别（可尝试 READ COMMITTED）、更新条件是否命中索引
- Buffer Pool 不足 → 观察 innodb_buffer_pool_reads / innodb_buffer_pool_read_requests 比率，若 > 1%，说明物理读频繁，需扩容或优化热点数据访问模式
优化后必须回归原压测场景，确认目标指标达标且无副作用（如其他接口变慢、主从延迟增大）。
