sysbench测mysql主从性能不能直接测复制延迟，而是验证主库写入压力下从库能否跟上、读一致性是否受损、读扩展是否有效；需用oltp_write_only或oltp_read_write压主库，独立连接池压从库并禁用事务，严格匹配从库硬件配置参数，实时监控seconds_behind_master与sql线程状态，并关注网络带宽及binlog格式影响。
sysbench 做 MySQL 主从复制性能测试时，不能直接测“复制延迟”，它只测主库写入能力 + 从库读取能力的组合表现。你要测的是：**在主库持续写入压力下，从库能否跟上、读一致性是否受损、读扩展是否真有效**。关键不是堆高并发，而是让参数暴露主从链路瓶颈。
主库写压测必须用 oltp_write_only 或 oltp_read_write
主从场景下，主库只承担写入（或写多读少），所以 prepare 和 run 阶段要明确区分写负载类型：
-
oltp_write_only：纯写（insert/update/delete），适合测主库吞吐上限和 binlog 生成压力，也最能暴露主库 IOPS 或 CPU 瓶颈 -
oltp_read_write：混合读写（默认比例 70% read / 20% write / 10% other），更贴近真实业务，但会掩盖主库纯写能力——因为部分线程在查主库，干扰了对从库读能力的独立评估 - 别用
oltp_read_only直接压主库，那等于绕过主从架构，测的只是单点读性能
从库读压测需隔离连接，且禁用事务控制
从库读压力必须走独立连接池，不能和主库共用同一套 --mysql-host 参数。常见错误是把所有 sysbench 实例都指向主库地址，结果根本没压到从库。
- 显式指定从库地址：
--mysql-host=192.168.1.102 --mysql-port=3306（确保该 IP 是从库） - 强制跳过事务：
--skip-trx=1，否则oltp_read_only默认会用BEGIN/COMMIT，而从库可能因只读模式报ERROR 1290 (HY000): The MySQL server is running with the --read-only option - 加
--report-interval=1实时观察 QPS 波动，便于发现从库延迟突增（比如 QPS 突降、RT 跳升）
--table_size 和 --tables 要匹配从库硬件，别照搬主库配置
主库通常配 SSD + 大内存，从库可能是 SATA 盘 + 少内存。如果 --table_size=10000000 --tables=16 在主库跑得稳，放到从库可能因 buffer pool 不足导致大量磁盘 IO，QPS 断崖下跌——这不是复制慢，是读能力差。
- 从库压测前先估算：InnoDB 缓冲池应 ≥ 单表热数据 × 表数量 × 1.5；若从库只有 4GB 内存，
--table_size=1000000比10000000更合理 -
--tables建议从 4 开始试，逐步加到 16/32，观察SHOW SLAVE STATUS\G中的Seconds_Behind_Master是否稳定 ≤ 1 - 避免用
--rand-init=on同时初始化主从——主库 prepare 完后，从库需要时间追平，此时立刻 run 读压测，会读到空表或部分数据，结果不可信
必须监控 Seconds_Behind_Master 和 slave_sql_running_state
sysbench 输出的 TPS/QPS 是表象，真正决定主从可用性的，是复制线程状态。光看 sysbench 报告里 “transactions: 12000 (32.4 per sec)” 没意义。
- 开一个终端持续执行：
watch -n 1 "mysql -usysbench -p'xxx' -e 'SHOW SLAVE STATUS\G' | grep -E 'Seconds_Behind_Master|SQL_Running|State:'" - 重点盯
Seconds_Behind_Master是否持续增长（说明 SQL thread 跟不上）、Slave_SQL_Running_State是否卡在Waiting for dependent transaction to commit（MGR 或并行复制依赖问题） - 如果
Seconds_Behind_Master稳定在 0–2，但sysbench读请求 RT 突然拉长，大概率是锁冲突或 MVCC 版本链过长，不是复制问题
ROW 格式 + 大字段更新，主库发给从库的 binlog 流量可能吃满千兆网卡，这时调再高的 --threads 也没用——Sysbench 显示的低 TPS，其实是网络层卡住了，不是数据库慢。
