AFTER_SYNC是主库写入卡死的直接原因，因其要求主库在binlog刷盘后、InnoDB提交前阻塞等待从库ACK，而ACK仅表示relay log缓冲区写入成功，并非落盘或执行完成，网络抖动或从库延迟均会导致主库卡住。
rpl_semi_sync_master_wait_point 设为 AFTER_SYNC 是主库写入卡死的直接原因
MySQL 5.7+ 默认启用 rpl_semi_sync_master_wait_point = AFTER_SYNC，这意味着主库必须完成三步才能返回客户端：
- 执行事务（InnoDB 提交）
- 将 binlog 刷盘（
sync_binlog=1时尤其关键） - 等待至少一个从库返回 ACK
这第三步就是卡点。ACK 只表示从库已将 binlog 写入 relay log 缓冲区（非落盘、非执行），但主库不区分快慢，一律阻塞等待。一旦网络抖动、从库 TCP 接收队列满、或内核 net.ipv4.tcp_rmem 设置过小，ACK 就延迟甚至丢失，主库就卡在提交阶段。
slave_compressed_protocol=ON 在 MySQL 5.7.19 及更早版本会触发 30 秒硬卡顿
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
这不是配置错误，是真实 Bug：半同步插件无法解析压缩协议下的 ACK 包，导致主库永远收不到有效响应。那个“30 秒”，本质是 master_heartbeat_period 的默认值（30000 毫秒），不是超时参数 rpl_semi_sync_master_timeout。
验证方式：
-
SHOW VARIABLES LIKE 'slave_compressed_protocol';返回ON→ 立即关掉 -
SHOW VARIABLES LIKE 'master_heartbeat_period';非零 → 说明心跳正在兜底，已出问题 - 错误日志出现
Read semi-sync reply magic number error→ 坐实该 Bug
修复只有三条路：关压缩、升级到 ≥5.7.21 或 ≥8.0.4、或两者都做。
rpl_semi_sync_master_wait_for_slave_count 设成 2 会让延迟概率指数级上升
设为 2 不等于“更可靠”，而是要求两个从库都发 ACK 才能提交。但 ACK 发送时机完全独立——只要其中任意一个从库稍慢（比如 IO 延迟高、relay log 写入卡在 fsync、甚至只是临时 GC），整个主库写入就被拖住。
生产环境里：
-
wait_for_slave_count = 1是合理底线 - 监控
Rpl_semi_sync_master_no_times和Rpl_semi_sync_master_off_times：如果这两项每小时增长几十次，说明不是参数问题，是某个从库真实存在瓶颈 - 查从库
SHOW PROCESSLIST，重点关注State是否长期卡在Waiting for master to send event或Queueing master event to the relay log
真正卡住主库的，往往不是半同步开关本身，而是它把底层问题暴露得更尖锐：网络 RTT 波动、从库 IO 能力不足、TCP 内核参数失配、甚至只是某台从库磁盘开始静默损坏。这些在异步复制下可能被掩盖，一开半同步就立刻显形。
