读写分离需应用层或中间件显式路由，MySQL自身不支持；主库只处理写，SELECT必须发往从库，否则主库压力过大；常见错误是误以为主从复制即自动读从库。
读写分离不是自动发生的，得靠应用层或中间件路由
MySQL 本身不提供读写分离能力，SELECT 和 INSERT/UPDATE/DELETE 都默认打到主库。所谓“读写分离”，本质是把 SELECT 请求显式发给从库，主库只承担写压力。这必须由上层控制——要么在代码里手动指定连接（比如用两个数据源），要么引入 ProxySQL、MaxScale 或 ShardingSphere-JDBC 这类中间件做自动路由。
常见错误是以为配置了主从复制就自动读从库，结果所有查询仍在主库执行，主库 CPU 和连接数持续飙高。
- 应用直连方式：需在业务代码中区分
writeDataSource和readDataSource，Spring Boot 可用@Transactional(readOnly = true)触发读库，但要注意事务内即使只读也会走主库 - 中间件方式：如
ProxySQL支持基于 SQL 注释（/*+ READ_FROM_SLAVE */）或规则匹配（如匹配SELECT开头）分流，但需注意SELECT ... FOR UPDATE必须走主库，否则报错 - 从库延迟导致查不到最新数据：例如用户注册后立刻查个人信息，可能因主从延迟返回空，需对强一致性场景强制走主库
主从延迟大时，SHOW SLAVE STATUS 的 Seconds_Behind_Master 并不可信
这个值在 MySQL 5.7+ 中基于 GTID 和事件时间戳计算，但遇到大事务、网络抖动或从库 IO 压力大时会跳变甚至归零假象。更可靠的方式是用半同步 + 延迟监控表：在主库定时写入带时间戳的记录（如 INSERT INTO heartbeat(ts) VALUES (NOW())），从库查该记录与当前时间差，才是真实延迟。
延迟直接影响读写分离效果。如果平均延迟 2 秒，那所有“刚写完就查”的场景都得绕过读写分离逻辑。
- 避免在从库执行
ALTER TABLE或OPTIMIZE TABLE，这类操作会阻塞 SQL 线程，瞬间拉高Seconds_Behind_Master - 从库建议关闭
innodb_flush_log_at_trx_commit=2和sync_binlog=0（仅限从库），提升回放速度，但要接受极端宕机下最多丢失 1s 事务 - 大表
JOIN查询尽量不下推到从库，CPU 和内存压力会拖慢复制线程
主从架构下权限和账号要分设，别复用主库账号
从库账号只需 SELECT 权限，且应限定只允许从应用服务器 IP 连接。若用主库账号（如 root 或具备 REPLICATION CLIENT 的账号）直接连从库，等于暴露高危权限，一旦泄露可被用于提权或 dump 全量数据。
典型错误是 Spring Boot 的 readDataSource 配置和 writeDataSource 共用同一套 username/password，导致从库连接实际拥有写权限。
- 建专用只读账号：
CREATE USER 'app_ro'@'10.0.1.%' IDENTIFIED BY 'xxx'; GRANT SELECT ON mydb.* TO 'app_ro'@'10.0.1.%'; - 主库账号至少禁用
FILE、PROCESS、SUPER权限；从库账号禁止INSERT、UPDATE、DROP等任何写权限 - 应用连接字符串中明确指定
allowPublicKeyRetrieval=true和useSSL=false（若未配证书），否则某些驱动版本会拒绝连接从库
不要忽略从库的监控和自动摘除机制
从库挂了或复制中断时，如果流量还在往它身上导，会导致查询失败或超时。不能只靠 SHOW SLAVE STATUS 手动巡检，得有自动化检测：比如每 5 秒用 SELECT @@slave_sql_running, @@slave_io_running 检查线程状态，结合心跳表延迟判断是否健康。
中间件或客户端 SDK 需支持“故障摘除 + 自动恢复”：发现某从库连续 3 次检查失败，就临时剔除，等它恢复后再加回负载池。否则一个从库卡死，整个读流量会压垮剩下几个节点。
-
ProxySQL可通过mysql_servers表的status字段控制上线/下线，配合monitor模块自动刷新 - 若用 Spring Cloud LoadBalancer，需自定义
ReactorServiceInstanceListSupplier实现健康检查逻辑，不能只依赖连接池 ping - 特别注意：MySQL 8.0.22+ 的
clone plugin虽能快速重建从库，但克隆过程会锁表，不适合在线热修复
从库不是主库的廉价备份，它是读流量的承压面，也是延迟、权限、监控三重风险的交汇点。很多人调通复制就以为万事大吉，其实真正的难点在如何让读请求既分得出去，又不出错、不丢数据、不越权。
