MySQL主从复制未建立导致Seconds_Behind_Master为NULL，主因是CHANGE MASTER TO参数错误或server_id冲突；读写分离选型需据场景定：ProxySQL适合灵活路由，MaxScale适配MGR集群；事务内及锁查询强制走主库，延迟本质是主从间固有时间窗口。
MySQL 主从复制配不通，SHOW SLAVE STATUS 里 Seconds_Behind_Master 一直是 NULL？
主从没真正连上，不是延迟高，是压根没同步。常见原因是 CHANGE MASTER TO 里用了错误的 MASTER_LOG_FILE 和 MASTER_LOG_POS，或者从库的 server_id 和主库重复。
- 先在主库执行
SHOW MASTER STATUS，记下当前File和Position，别用 mysqldump 导出时的旧位点 - 从库
server_id必须全局唯一，且不能为 1（主库默认值），建议设成数字 IP 最后一段，比如192.168.1.10就配server_id = 10 - 如果主库开了
binlog_format = ROW，从库也得保持一致；混用MIXED或STATEMENT可能导致某些语句不写 binlog，从库就收不到
读写分离中间件选 ProxySQL 还是 MaxScale？
ProxySQL 上手快、规则灵活，但监控和故障自动切换弱；MaxScale 对 MySQL 集群协议理解更深，自带 mysqlmon 健康检查，但配置粒度粗、调试日志不够直白。
- 小团队、读多写少、需要按 SQL 拆分路由（比如把
SELECT count(*)固定发到某台从库），优先ProxySQL - 用到了 MGR 或 InnoDB Cluster，必须选
MaxScale，它原生支持group_replication成员状态感知，ProxySQL得靠外部脚本轮询 - 两者都不直接支持事务内读写分离——一旦
BEGIN，后续所有语句都会被发到主库，这是对一致性最基本的保障，别试图绕过
SELECT 被发到主库了，但明明没写操作？
不是中间件抽风，是客户端连接没关 autocommit，或者上一条语句触发了隐式事务（比如 INSERT ... ON DUPLICATE KEY UPDATE）。
- 检查应用层连接池是否设置了
autocommit=true，很多 ORM 默认关掉它 - 用
SELECT @@in_transaction在从库查一下，如果是 1，说明当前会话还在事务里，哪怕你没显式BEGIN -
SELECT FOR UPDATE和SELECT LOCK IN SHARE MODE永远走主库，这是隔离级别要求，没法改
从库延迟突然飙到几万秒，Seconds_Behind_Master 却卡在 0？
说明 IO 线程正常，但 SQL 线程根本没跑——大概率是某个 DDL 卡住了，比如 ALTER TABLE 在大表上执行，或者从库启用了 slave_parallel_workers > 0 但碰上了不支持并行的语句，导致协调线程阻塞。
- 看
SHOW PROCESSLIST里有没有Waiting for dependent transaction或Waiting for table metadata lock - 临时降级：设
SET GLOBAL slave_parallel_workers = 0，让 SQL 线程串行跑，至少能追平 - 长期方案：主库做 DDL 前先
SET SESSION binlog_format = 'ROW'，避免从库解析失败；大表变更用pt-online-schema-change，别直接ALTER
主从延迟不是数字问题，是时间窗口问题。哪怕 Seconds_Behind_Master 显示为 0，只要主库刚写入一行，从库还没落盘，那这一行对读请求就是不可见的——这个窗口期，永远存在。
