master_heartbeat_period设置不当会导致seconds_behind_master失真：设为0时延迟掩盖io断连，设太长（如120秒）延长故障感知，设太短（如0.1秒）徒增开销；必须小于slave_net_timeout（如默认60秒时建议≤40），且需stop/start slave生效。
MASTER_HEARTBEAT_PERIOD 设置不当会导致 Seconds_Behind_Master 失真
心跳不是用来“测主库死活”的，而是让从库在主库静默时仍能更新 Exec_Master_Log_Pos 和 Relay_Log_Pos。如果设为 0（默认），主库无写入时，Seconds_Behind_Master 就会卡住不动——它看起来是 0，但实际 IO 线程可能早已断开或滞后；也可能长期显示某个固定值，掩盖了拉取延迟。
- 设得太长（比如 120 秒），主库宕机后从库要等两分钟才感知到连接异常
- 设得太短（比如 0.1 秒），主库每秒发 10 个空事件，徒增网络和线程调度压力
- 真实延迟必须结合
Read_Master_Log_PosvsExec_Master_Log_Pos、Last_IO_Error和Slave_IO_Running综合判断
必须小于 slave_net_timeout，否则心跳反而触发重连
slave_net_timeout 是从库等待主库下一个事件的上限（单位秒）。若 MASTER_HEARTBEAT_PERIOD ≥ 这个值，从库收不到心跳就直接判定超时，IO 线程断开重连——你本想保活，结果制造了抖动。
- MySQL 8.0 默认
slave_net_timeout = 60，所以心跳建议 ≤ 40，常见设为 30 或 20 - 若手动调小
slave_net_timeout（如设为 30），则MASTER_HEARTBEAT_PERIOD必须同步下调，不能只改一个 - 修改需停复制：
STOP SLAVE→CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 20→START SLAVE
小数精度支持但慎用，尤其在高并发主库上
MySQL 允许把 MASTER_HEARTBEAT_PERIOD 设成小数（如 1.5），精度可达毫秒级。但这不等于更可靠——主库 binlog dump 线程要定时唤醒、构造并发送 Heartbeat_log_event，频繁唤醒会影响高负载下的事务吞吐。
- 线上环境优先用整数：1、5、10、30、60 秒，避免调度抖动
- 低于 1 秒的心跳（如 0.5）只适合极低延迟局域网+低流量场景，云环境或跨机房慎用
- GTID 模式下心跳携带
last_committed信息，但binlog_format = STATEMENT时对NOW()类函数无额外保障
查看与验证心跳是否真正生效
光看 SHOW SLAVE STATUS\G 里的 Master_Heartbeat_Period 不够，得确认从库实际收到了心跳且位置在推进。
- 查实时统计：
SELECT * FROM performance_schema.replication_connection_status\G，关注LAST_HEARTBEAT_TIMESTAMP和RECEIVED_HEARTBEATS - 抓包验证：
tcpdump -i any port 3306 and host master_ip，观察是否有规律的空包（长度约 20–30 字节） - 错误线索：
Last_IO_Error出现 “heartbeat timeout” 或 “connection lost” 说明配置冲突或网络丢包
心跳机制本身很简单，但它的作用高度依赖 slave_net_timeout、主库负载、网络路径稳定性三者的配合。单独调一个参数，往往治标不治本。
