MySQL主从复制心跳检测由MASTER_HEARTBEAT_PERIOD参数控制，需在CHANGE MASTER TO中显式指定，单位秒（支持小数），仅在启用GTID或ROW格式且slave_net_timeout开启时生效。
MySQL主从复制心跳检测靠什么参数控制
主从复制的心跳检测由 MASTER_HEARTBEAT_PERIOD 控制，它不是全局变量，也不能在配置文件里直接写；必须在执行 CHANGE MASTER TO 时显式指定，单位是秒（支持小数，如 0.5 表示 500ms）。
这个参数只对启用 GTID 或启用了基于行复制（ROW）且从库开启了 slave_net_timeout 的场景才真正起作用——心跳包本质是主库在空闲时主动发的 COM_HEARTBEAT 指令，用于让从库判断连接是否还活着，避免因网络假死导致 IO 线程卡住不报错。
设置 MASTER_HEARTBEAT_PERIOD 的实操步骤
必须先停掉从库复制，再用 CHANGE MASTER TO 重配（即使其他参数不变）：
STOP SLAVE; CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 1.0; START SLAVE;
注意以下几点：
-
MASTER_HEARTBEAT_PERIOD值必须大于 0，且建议 ≤slave_net_timeout的一半（例如slave_net_timeout=60，则心跳设为30或更小），否则心跳来不及触发超时判定 - 该参数不会自动持久化到
master.info文件（旧版本）或表（5.7+ 的mysql.slave_master_info），重启从库后需重新设置，除非你把整个CHANGE MASTER TO命令写进启动脚本 - 如果主库 MySQL 版本
为什么改了心跳周期，Seconds_Behind_Master 还是 NULL 或不准
心跳检测只影响 IO 线程的连接存活判断，不影响 SQL 线程的执行延迟统计。常见误解是以为调小心跳就能“更快发现延迟”，其实：
-
Seconds_Behind_Master是 SQL 线程对比当前时间与 relay log 中 event timestamp 得出的，和心跳无关 - 若主库长时间无写入，relay log 不更新，
Seconds_Behind_Master就会显示NULL（表示无法计算），这不是心跳没起作用，而是没数据可追 - 真正影响延迟感知的是
slave_net_timeout+MASTER_HEARTBEAT_PERIOD组合：只有当主库连续slave_net_timeout秒没发任何包（含心跳），IO 线程才会报错重连
容易被忽略的兼容性陷阱
心跳机制在不同复制模式下表现差异很大：
- 使用传统基于语句（SBR）复制时，心跳包可能被主库忽略（尤其低版本），因为 SBR 下主库不保证空闲时发心跳
- GTID 模式下最稳定，但要求
enforce_gtid_consistency=ON且主从都开启 GTID - MySQL 8.0.22+ 引入了
MASTER_COMPRESSION_ALGORITHMS和MASTER_ZSTD_COMPRESSION_LEVEL，若开启压缩，心跳包也会被压缩，某些中间件或防火墙可能误判为异常流量而丢弃 - 云环境（如阿里云 RDS、AWS RDS）通常屏蔽了
CHANGE MASTER TO的部分参数，MASTER_HEARTBEAT_PERIOD可能被拒绝设置，得查对应平台文档确认是否开放
心跳不是万能的健康探针，它只管链路层存活。真要监控复制质量，还得结合 SHOW SLAVE STATUS 中的 Slave_IO_Running、Slave_SQL_Running、Retrieved_Gtid_Set 和 Executed_Gtid_Set 对比，以及定期检查 relay_log_space_limit 是否快满。
