MySQL只读模式需分层设置：read_only仅限制普通用户，super_read_only才能拦截root等SUPER权限用户，且必须先启用read_only；云数据库需通过控制台配置，无法直接执行SET GLOBAL。
MySQL 设置只读模式不是“开个开关就万事大吉”，关键看你要拦谁、拦到什么程度。临时设 read_only = ON 只能拦普通用户；要拦 root 或其他 SUPER 用户，必须用 super_read_only，且它依赖 read_only 先开启。
为什么 SET GLOBAL read_only = ON 后 root 还能写？
这是 MySQL 的设计行为，不是配置错误。read_only 本意就是“软只读”——只拦截没有 SUPER 权限的账号。root 默认带 SUPER，所以 INSERT/UPDATE/DELETE 全部照常执行。
- 验证当前用户是否被限制：用普通账号（如
app_user）连接后执行INSERT INTO t1 VALUES (1)，应报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement - 检查权限：执行
SELECT CURRENT_USER(), @@session.super_priv，确认你连的是不是高权限账号 - 别指望靠
read_only做安全隔离——它不替代权限系统，只是操作层拦截
如何真正禁止所有写操作（含 root）？
必须启用 super_read_only，且它在 MySQL 5.7.8+ 才可用。它不是独立开关，而是增强版：super_read_only = ON 会自动把 read_only 也设为 ON；反过来，read_only = OFF 也会强制清掉 super_read_only。
- 在线启用（重启前有效）：
SET GLOBAL super_read_only = ON - 永久生效：在
my.cnf的[mysqld]段下加两行：read_only = ON<br>super_read_only = ON
注意：值必须是ON或OFF，不能写1、true或yes - 启用后，root 执行写操作也会报
ERROR 1290，连创建函数、存储过程、EVENT、安装插件等管理类写操作也被禁止 - 但复制线程（如
sql_thread）仍可正常应用 relay log，主从同步不受影响
云数据库（如阿里云 RDS、腾讯云 CDB）怎么设？
这类服务通常禁用 SET GLOBAL，也不开放配置文件修改权限。你无法直接执行 SET GLOBAL read_only = ON，更别说 super_read_only。
- 必须通过控制台或 OpenAPI 设置只读模式，路径一般是「参数设置」→ 找
read_only或「只读实例开关」 - 部分云厂商提供「强制只读」选项，底层实际启用了
super_read_only行为，但对外不暴露变量名 - 如果控制台没提供对应开关，说明该实例不支持运行时只读控制，只能靠网络层（如代理、防火墙）阻断写流量，或提前回收应用账号的写权限
维护完成后怎么安全恢复读写？
别只关 super_read_only ——因为 read_only = OFF 会自动清掉 super_read_only，但如果你之前没手动关过 read_only，它可能还挂着，导致误判。
- 推荐一步到位：
SET GLOBAL read_only = OFF（这会同时关闭super_read_only） - 验证是否生效：
SELECT @@global.read_only, @@global.super_read_only，两个都应返回0 - 特别注意：已存在的活跃事务不会被中断，但新事务可以正常提交；未提交的事务只能回滚，不能强行提交
- 如果维护期间用了
FLUSH TABLES WITH READ LOCK，务必配对执行UNLOCK TABLES，否则表锁一直挂着，连 SELECT 都会被卡住
最易忽略的一点：只读模式对临时表（CREATE TEMPORARY TABLE）、日志清理（PURGE BINARY LOGS）、ANALYZE TABLE 等操作默认不拦截，哪怕开了 super_read_only。真要彻底冻结一切变更，得配合文件系统级只读或运维流程管控。
