默认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设置）
