MySQL主从复制下read_only必须设为ON，以防止从库误写导致同步中断；需在my.cnf中配置并重启，同时回收SUPER权限，并配合super_read_only保障严格只读。
MySQL 主从复制下 read_only 参数为什么必须设为 ON
主库写入、从库只读是读写分离的底线，但仅靠应用层路由无法防止误操作。一旦从库被手动写入，后续主从同步会中断，error 1236 (hy000) 或 seconds_behind_master: null 就是典型信号。
实操建议：
-
read_only=ON必须在从库的my.cnf中配置并重启生效；仅执行SET GLOBAL read_only = ON是临时的，重启后丢失 - 该参数不影响 SUPER 权限用户，所以要同时回收从库账号的
SUPER权限，否则INSERT/UPDATE仍可绕过 - 注意
read_only不阻拦 DDL（如CREATE TABLE），若业务需严格只读，还得配合super_read_only=ON（MySQL 5.7.8+）
用 mysqlrouter 做透明读写分离时，连接池行为怎么调
MySQL Router 默认不维护长连接池，每次请求都新建 TCP 连接，高并发下容易触发 Too many connections 或 Can't connect to MySQL server。它只是路由代理，不是连接池中间件。
实操建议：
- 在应用侧启用连接池（如 Python 的
mysql-connector-python设置pool_size=10），Router 层不做池化 - Router 配置中
[routing:read-write]段的max_connections是单节点上限，不是总连接数，别误设成 1000 导致主库被打满 - 测试时用
mysqladmin -h 127.0.0.1 -P 6446 extended-status | grep Threads_connected看实际连接分布，确认读请求真到了从库
Java 应用里用 jdbc:mysql:// URL 实现读写分离失败的三个常见原因
很多人以为加个 &loadBalanceAutoCommitStatementThreshold=5 就能自动分发读写，其实 JDBC 驱动本身不解析 SQL 语义，所谓“读写分离”只是轮询或权重转发，和 SQL 类型无关。
实操建议：
- 真正支持语法级读写分离的是
mysql-connector-java8.0+ 的replication方式：URL 要写成jdbc:mysql:replication://master-host:3306,slave-host:3306/db?allowMultiQueries=true - 必须显式调用
conn.setReadOnly(true)才走从库，否则永远走第一个 host（即 master） - 事务内所有语句强制走主库，哪怕你已调用
setReadOnly(true)，这点常被忽略，导致事务中查到脏数据或报错Transaction isolation level can't be changed inside transaction
验证主从延迟是否影响读写分离效果的最快命令
应用连上从库查出旧数据，第一反应是“路由错了”，但更大概率是主从延迟没被感知——尤其在批量导入或大事务后，Seconds_Behind_Master 可能卡在 0 却实际落后几万行。
实操建议：
- 别只看
SHOW SLAVE STATUS\G里的Seconds_Behind_Master，它基于 GTID 或 relay log 时间戳，有滞后性；直接查SELECT UNIX_TIMESTAMP() - UNIX_TIMESTAMP(utc_timestamp())在主从两端对比，更准 - 用
pt-heartbeat工具持续打点，比人工查快；其原理是在主库定时更新一张表，从库读该时间戳算差值 - 如果业务对一致性敏感（如订单支付后立即查详情），不要依赖从库，改用主库读，或引入
SELECT ... FOR UPDATE+ 主库强一致查询
主从延迟不是网络问题，而是从库 SQL 线程单线程回放瓶颈，扩容从库数量或升级为并行复制（slave_parallel_workers > 0）才能根治，单纯调优路由没用。
