必须同时设置 read_only=1 和 super_read_only=1 才能真正禁止写入，因 read_only 对 super 权限用户无效；需检查变量作用域、持久化配置及 mysql 版本兼容性。
从库 read_only=1 但还能写入？先查 super_read_only
MySQL 5.7+ 引入了 super_read_only，它比 read_only 更严格：即使有 SUPER 权限的用户，也无法绕过。如果只设了 read_only=1 而没开 super_read_only，拥有 SUPER 权限的账号（比如 root、监控账号、运维账号）仍能执行写操作。
实操建议：
- 连上从库，运行
SELECT @@read_only, @@super_read_only;—— 两个都必须是1才真正锁死写入 - 若
super_read_only是0，立即执行SET GLOBAL super_read_only = 1; - 别忘了写进配置文件（
my.cnf），否则重启后失效：[mysqld] read_only = 1 super_read_only = 1
- 注意：开启
super_read_only后，SET GLOBAL read_only = 0也会被拒绝，哪怕你是SUPER用户
哪些账号会绕过 read_only？重点审计 SUPER 权限持有者
read_only 本身对 SUPER 权限用户无效 —— 这是 MySQL 的设计行为，不是 bug。很多线上事故都源于“以为加了 read_only 就万事大吉”，结果 DBA 或备份工具用 root 登录后误执行了 INSERT 或 DROP。
实操建议：
- 查所有带
SUPER权限的账号：SELECT User, Host FROM mysql.user WHERE Super_priv = 'Y'; - 确认这些账号是否真需要
SUPER：多数场景下，用REPLICATION SLAVE、PROCESS、RELOAD等细粒度权限就够了 - 降权操作示例：
REVOKE SUPER ON *.* FROM 'backup'@'%'; GRANT REPLICATION SLAVE, PROCESS ON *.* TO 'backup'@'%'; - 特别注意：Percona Toolkit、pt-heartbeat、某些云厂商的监控 agent 默认用 root 连接，它们可能触发写入
read_only 在 GTID / MGR 环境下表现不同？别依赖单一开关
在基于 GTID 的复制或 MySQL Group Replication（MGR）中，read_only 的行为会受复制状态影响。例如 MGR 中，节点离开集群后自动退出 READ_ONLY 模式（为避免脑裂，它认为自己是唯一可写节点），这时 read_only=1 可能被覆盖。
实操建议：
- MGR 环境下必须同时检查
group_replication_single_primary_mode和super_read_only，仅靠read_only不可靠 - GTID 复制中，如果从库延迟严重或 IO/SQL 线程停止，
read_only仍生效，但要注意：应用层连接池可能缓存了旧连接，误发写请求到从库 - 建议在应用侧增加读写分离中间件（如 ProxySQL、MaxScale）的路由规则校验，而不是只靠数据库端防护
为什么 read_only 突然失效？排查顺序优先看变量作用域和持久化
常见现象是：昨天还只读，今天突然能写；或者主从切换后从库写入不受控。根本原因往往不是配置逻辑错，而是变量没生效或被覆盖。
实操建议：
- 区分会话级 vs 全局级：
SET read_only = 1是会话级，只影响当前连接；必须用SET GLOBAL read_only = 1 - 确认是否被启动脚本或自动化工具重置：检查
mysqld_safe启动参数、Ansible playbook、Docker entrypoint 是否含--read-only=0 - 查看生效来源：
SELECT VARIABLE_NAME, VARIABLE_SOURCE, VARIABLE_PATH FROM performance_schema.variables_info WHERE VARIABLE_NAME IN ('read_only', 'super_read_only');—— 如果VARIABLE_SOURCE是COMPILED或COMMAND_LINE，说明配置被硬编码或命令行覆盖 - 重启后失效？说明没写进
my.cnf，或者写错了 section（比如写在[client]下而非[mysqld]）
最容易被忽略的是：super_read_only 在 MySQL 5.7.20+ 才默认启用，低版本升级后不显式设置就等于没锁住 SUPER 用户。别假设版本行为一致。
