seconds_behind_master为null说明主从同步链路中断，常见原因有主库未启用binlog、从库change master to参数错误、网络或复制账号权限问题。
主从复制没跑通，SHOW SLAVE STATUS 里 Seconds_Behind_Master 一直是 NULL
说明从库根本没连上主库，不是延迟问题，是同步链路断了。常见原因有三个：
一是主库没开 binlog（检查 my.cnf 里有没有 log-bin=mysql-bin 和 server-id）；
二是从库执行过 CHANGE MASTER TO 但主库的 master_log_file 或 master_log_pos 填错了，尤其容易把主库 SHOW MASTER STATUS 的结果抄错位；
三是网络或权限问题——从库用的复制账号（比如 repl@'%' ）必须有 REPLICATION SLAVE 权限，且主库防火墙要放行 3306 端口。
读写分离中间件选 ProxySQL 还是 MaxScale？
ProxySQL 更轻量、配置灵活，适合中小流量和需要 SQL 改写（比如自动把 SELECT 路由到从库）的场景；MaxScale 对 MySQL 协议解析更严谨，自带监控面板，但资源占用高，升级路径稍复杂。两者都支持权重轮询和故障自动摘除，但注意：
– ProxySQL 的路由规则靠 mysql_query_rules 表维护，改完要 LOAD MYSQL QUERY RULES TO RUNTIME 才生效；
– MaxScale 的 readwritesplit 模块默认不转发事务内的 SELECT，避免从库读到未提交数据，这点容易被忽略；
– 无论用哪个，应用层都别依赖“刚写完立刻能读到”，因为主从复制有天然延迟。
从库执行 SELECT 报错 ERROR 1236 (HY000): Could not find first log file name in binary log index file
这是典型的 binlog 文件被主库清理了，但从库还没来得及拉取完。主库的 expire_logs_days 设太小（比如默认 0 或 3 天），而从库因网络抖动、大事务阻塞等原因 lag 时间超过保留窗口，就会触发这个错误。解决方法只有两个：
– 立即停掉从库，用 mysqldump + --master-data=2 重新搭建从库（最稳妥）；
– 或者临时调大主库 expire_logs_days，再手动找一个从库还能追上的 binlog 位置（查 SHOW BINARY LOGS 和从库 Relay_Master_Log_File），但风险高，不推荐线上用。
为什么应用连了读写分离中间件，还是偶尔读到旧数据？
不是中间件坏了，是 MySQL 主从复制本身不保证强一致性。即使 Seconds_Behind_Master = 0，也可能因为并行复制（slave_parallel_workers > 0）导致部分事务在从库回放顺序和主库不一致，或者半同步（rpl_semi_sync_master_enabled）没开，主库提交就返回成功，实际日志还没传到从库。如果业务对实时性敏感（比如订单支付后立即查状态），必须在写操作后加 SELECT ... FOR UPDATE 或显式走主库连接，不能无条件信任“读从库”。
