默认sysbench脚本无法测出半同步真实瓶颈，因其autocommit=1下每条INSERT独立提交，不触发COMMIT时的等待逻辑；需显式长事务（如--trx-num=10）、调通半同步状态、监控Rpl_semi_sync_master_no_times等指标才能暴露超时降级与阻塞风险。

不能直接用默认 sysbench 脚本测出半同步的真实性能瓶颈。它默认走单点写入、不触发主库等待逻辑，压测结果会严重高估吞吐，掩盖 rpl_semi_sync_master_timeout、wait_for_slave_count 和网络抖动带来的阻塞风险。

为什么 oltp_write_only.lua 压不出半同步效果

sysbench 的 oltp_write_only.lua 默认每事务只写一张表、无显式事务控制，MySQL 在 autocommit=1 下每条 INSERT 都是独立事务。而半同步的等待行为只在 COMMIT 时触发 —— 如果从库 ACK 延迟高，主库会卡在 commit 阶段，但 sysbench 客户端感知为“慢查询”，不会报错或降级，容易误判为 SQL 性能问题。

• 必须显式开启长事务（--trx-num 或改写脚本），让多个 DML 聚合成一个 COMMIT
• 默认 --time=60 太短，无法暴露超时后自动降级为异步复制的拐点
• 未设置 --db-driver=mysql 且连接参数缺失 mysql_init_command=SET SESSION binlog_format='ROW'，可能导致主从不一致或半同步不生效

压测前必须调通的半同步状态检查项

在跑任何 sysbench 之前，先确认半同步处于 active 状态，否则压测毫无意义：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 主库执行：SELECT @@rpl_semi_sync_master_enabled, @@rpl_semi_sync_master_timeout, @@rpl_semi_sync_master_wait_point; —— 确保第一个值为 ON，超时值建议设为 1000000（1秒），避免频繁降级
• 从库执行：SELECT @@rpl_semi_sync_slave_enabled; —— 必须为 ON
• 主库查状态：SHOW STATUS LIKE 'Rpl_semi_sync_master_status'; —— 返回 ON 才代表当前有效；若为 OFF，看 Rpl_semi_sync_master_no_times 是否增长，说明已多次超时降级
• 网络层用 ping -c 5 slave_ip 和 tcpping -x 5 slave_ip 3306 检查 RTT 和端口可达性，半同步对网络敏感，RTT > 10ms 就可能触发超时

推荐的 sysbench 命令与关键参数含义

以下命令专为暴露半同步行为设计，不是通用压测模板：

sysbench oltp_write_only.lua \
--tables=8 \
--table-size=50000 \
--db-driver=mysql \
--mysql-host=192.168.121.131 \
--mysql-port=3306 \
--mysql-user=sbtest \
--mysql-password=SecurePass123! \
--mysql-db=test \
--mysql-init-command="SET SESSION binlog_format='ROW'" \
--threads=16 \
--time=300 \
--report-interval=10 \
--auto-inc=0 \
--trx-num=10 \
run

• --trx-num=10：每事务含 10 条 INSERT，强制 commit 频率降低，放大等待效应
• --report-interval=10：每 10 秒输出一次 TPS/QPS，方便观察是否出现阶梯式下跌（典型降级信号）
• --auto-inc=0：关闭自增主键，避免主从冲突导致 SQL_THREAD 停止，干扰半同步判断
• 务必搭配 watch -n 1 'mysql -e "SHOW STATUS LIKE \"Rpl_semi%\""' 实时盯住 Rpl_semi_sync_master_no_tx（成功等待数）和 Rpl_semi_sync_master_no_times（降级次数）

最容易被忽略的三个现象

压测中如果只看 TPS 和错误率，会错过半同步最关键的运行态信号：

• Rpl_semi_sync_master_status 在压测中途变为 OFF，但 sysbench 不报错 —— 这是超时后自动降级为异步的明确标志，需立刻查 Rpl_semi_sync_master_no_times 是否突增
• 从库 Seconds_Behind_Master 持续 > 0，但 Rpl_semi_sync_slave_status 仍为 ON —— 说明 IO_THREAD 正常收日志，只是 SQL_THREAD 落后，不影响半同步等待逻辑
• 主库 Threads_running 突然飙升到接近 max_connections，同时 Com_commit 几乎停滞 —— 典型因从库 ACK 延迟导致主库 commit 线程排队，此时必须检查从库 relay log 写盘性能（如磁盘 IOPS、sync_relay_log=1 设置）