用sysbench标准oltp测试迁移后mysql真实吞吐量：需统一版本、线程数、时长及预热，设--tables=16--table-size=1000000，--time=300--threads=32，重点观察tps与p95延迟；务必调优innodb_buffer_pool_size至物理内存70%~80%，并排查wait_timeout、max_allowed_packet及死锁检测导致的延迟抖动。
怎么用 sysbench 快速跑出迁移后 MySQL 的真实吞吐量
别直接上复杂业务压测，先用 sysbench 跑标准 OLTP 场景，它能剥离应用层干扰，只反映 MySQL 本身在新库上的读写能力。关键不是“跑通”，而是让结果可比——旧库和新库必须用完全一致的 sysbench 版本、相同线程数、相同测试时长，且预热时间不能省。
- 用
sysbench 1.0.20+（低版本对 MySQL 8.0+ 的 prepared statement 支持不稳，容易误报MySQL thread stack overrun） - 表规模统一设为
--tables=16 --table-size=1000000，太小看不出 I/O 瓶颈，太大拉长单次测试周期 - 每次测试前执行
sysbench ... prepare，但不要反复cleanup—— 避免文件系统缓存被清空导致结果抖动 - 用
--time=300 --threads=32跑 5 分钟，比默认 10 秒更抗瞬时抖动；观察transactions per second和95th percentile latency两个值
为什么 innodb_buffer_pool_size 没调对，压测数据就全作废
迁移后最容易忽略的点：新服务器内存更大，但 my.cnf 还沿用旧配置。如果 innodb_buffer_pool_size 只设了 4G，而新机器有 64G 内存，那大部分热点数据根本进不了 Buffer Pool，压测时大量走磁盘，TPS 虚低、延迟虚高，你以为是磁盘慢，其实是配置没跟上。
- 生产环境建议设为物理内存的 70%～80%，但必须留够空间给 OS 和其他进程（比如备份工具、监控 agent）
- MySQL 5.7+ 支持在线调整，用
SET GLOBAL innodb_buffer_pool_size = 42949672960;（40G），再确认SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; - 改完立刻看
SHOW ENGINE INNODB STATUS\G里的Buffer pool hit rate，低于 990/1000 就说明还有大量物理读
sysbench 报 MySQL server has gone away 怎么定位真因
这不是网络问题，大概率是 MySQL 主动断开了长时间空闲连接，而 sysbench 没及时重连。尤其在高并发下，连接池复用不充分时极易触发。
- 先查 MySQL 的
wait_timeout和interactive_timeout，默认 28800 秒（8 小时），但如果压测中某线程卡住几秒，连接可能已被服务端 kill - 在
sysbench命令里加--mysql-ignore-errors=2013,2006（跳过 “server has gone away” 和 “connection lost”），避免整个测试中断 - 更治本的方法：在
my.cnf加max_allowed_packet = 64M并重启，防止大事务或长 SQL 触发连接重置
对比旧库和新库时，为什么 QPS 升了但 latency 更抖？
这是典型的 CPU 或锁竞争信号。QPS 看似提升，但响应时间分布拉宽（比如 P95 从 12ms 跳到 45ms），说明新库在高并发下稳定性下降，常见于未适配新版本的锁机制变化。
- MySQL 8.0 默认开启
innodb_deadlock_detect=ON，高并发更新同一批主键时，死锁检测开销变大，表现就是延迟毛刺增多 - 用
SHOW PROFILE FOR QUERY N;抓一个慢事务，重点看innodb_mutex_spin_waits和innodb_row_lock_time是否异常升高 - 临时缓解：把
innodb_thread_concurrency从 0 改成 32（限制并发线程数），观察抖动是否收敛；长期需优化 SQL 访问模式，减少行锁冲突
真正难的不是跑出两组数字，而是看懂 latency 分布曲线背后那几个突起的毛刺——它们往往藏在 slow_log 里，但只有开着 long_query_time=0.1 才抓得到。
