MySQL心跳不能防止虚假连接，因其仅由主库单向发送空事件告知“在线”，不验证TCP连接真实可达性或中间网络设备是否已静默断连；虚假连接本质是TCP层断连而双方未感知，需依赖slave_net_timeout触发重连，心跳仅辅助其精准判断。
心跳检测本身不解决“虚假连接”，它只解决“连接静默断开”——而你看到的 Slave_IO_Running: Connecting 状态，90% 是 slave_net_timeout 触发的主动重连，不是连接假活。
为什么心跳不能防止“虚假连接”？
MySQL 的心跳（MASTER_HEARTBEAT_PERIOD）是主库单向发空事件，仅用于告诉从库“我还在线”；但它不验证 TCP 连接是否真实可达、中间设备（防火墙/NAT/负载均衡）是否已悄悄 kill 掉长连接。所谓“虚假连接”，其实是 TCP 连接已断，但双方未触发 FIN/RST，从库 IO 线程还卡在 Connecting 等待握手响应——这属于网络层问题，心跳管不了。
-
MASTER_HEARTBEAT_PERIOD只影响主库是否发Heartbeat_log_event，不影响从库对连接状态的判断逻辑 - 从库真正决定“重连”的依据只有
slave_net_timeout：超时后无任何数据（含心跳事件）到达，就强制 close socket 并重试 - 如果网络中间设备 60 秒清空空闲连接，而你设
slave_net_timeout = 3600，那从库会傻等 1 小时才重连，期间Seconds_Behind_Master完全失真
必须同时调大 slave_net_timeout 并设合理心跳周期
单独设心跳没用，必须让 slave_net_timeout 和 MASTER_HEARTBEAT_PERIOD 形成配合关系，否则心跳包还没发出，从库就已经断开了。
- 先查当前值：
SHOW VARIABLES LIKE 'slave_net_timeout';（MySQL 8.0 默认是 60，5.7 是 3600） - 临时修改（立即生效但重启失效）：
SET GLOBAL slave_net_timeout = 30; - 永久修改：在从库
my.cnf的[mysqld]段加一行slave_net_timeout = 30 - 再配置心跳（单位必须是浮点数）：
STOP SLAVE; CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10.0; START SLAVE; - 推荐比例：
MASTER_HEARTBEAT_PERIOD设为slave_net_timeout的 1/3～1/2，例如后者为 30，则前者设 10.0 或 15.0
验证心跳是否真起作用
光看 SHOW SLAVE STATUS\G 里的 Master_Heartbeat_Period 字段不保险，得确认心跳事件实际被接收并更新了位置指针。
- 检查
Read_Master_Log_Pos和Exec_Master_Log_Pos是否在主库静默期仍缓慢增长（说明心跳事件被写入 relay log 并推进了位置） - 若
Seconds_Behind_Master在主库无写入时长期卡死不动，大概率心跳没生效或被丢弃 - 抓包验证（在从库执行）：
tcpdump -i any port 3306 -w heartbeat.pcap，然后过滤主库 IP，观察是否有规律的空包（长度约 50 字节左右的COM_HEARTBEAT协议帧） - MySQL 8.0+ 可查：
SELECT * FROM performance_schema.replication_connection_status WHERE CHANNEL_NAME = 'default'\G，关注LAST_HEARTBEAT_TIMESTAMP字段是否持续更新
容易被忽略的关键细节
心跳配置看似简单，但几个硬性约束常被跳过，导致白配：
-
MASTER_HEARTBEAT_PERIOD必须是浮点数（如10.0），传整数10会报错ERROR 1794 (HY000): The slave is configured with MASTER_HEARTBEAT_PERIOD = 0, which is not allowed - 修改后必须执行
STOP SLAVE; START SLAVE;，CHANGE MASTER TO不会热生效 - 心跳只对已建立的复制连接有效，如果
Last_IO_Error显示认证失败或网络拒绝，先解决底层连通性，再谈心跳 - 某些云厂商 RDS（如阿里云 PolarDB）禁用
CHANGE MASTER TO，需通过控制台或 API 配置，直接 SQL 会报权限错误
