仅设 read_only 不够安全，因 SUPER 权限用户可绕过；必须同时启用 super_read_only 并限制高危权限，才能实现真正只读。
为什么只设 read_only 不够安全
很多运维习惯性给从库加 read_only=ON，以为这就万无一失。但实际中，拥有 SUPER 权限的用户（比如 root、DBA 账号）仍能绕过该限制执行写操作——read_only 对 SUPER 用户完全无效。这意味着只要一个高权限账号连上从库并执行 INSERT 或 DROP TABLE，数据就立刻污染，主从不一致风险陡增。
常见误操作场景包括：DBA 临时登从库查数据时顺手删了测试表；监控脚本用 root 连从库做健康检查并意外触发清理逻辑；备份恢复脚本未区分主从，直接在从库执行 TRUNCATE。
-
read_only仅阻止普通用户写入，SUPER用户可无视 - MySQL 5.7.6+ 才支持
super_read_only，旧版本需升级或换方案 - 该变量是动态的，重启后不会自动生效，必须写进配置文件
必须同时启用 super_read_only 才算真正只读
开启 super_read_only 后，连 SUPER 权限用户也无法执行写语句（除少数元数据操作如 SET 变量），这才是防止误写的兜底手段。它和 read_only 是“与”关系：两个都 ON，整个实例才真正只读。
注意：启用 super_read_only 会自动将 read_only 设为 ON，但反过来不成立。所以生产环境必须显式设置两者。
- 启动时加配置：
super_read_only=ON和read_only=ON都要写进my.cnf的[mysqld]段 - 运行时动态开启（需 SUPER 权限）：
SET GLOBAL read_only = ON; SET GLOBAL super_read_only = ON; - 检查是否生效：
SELECT @@read_only, @@super_read_only;二者都应返回1 - 若主库也误开
super_read_only，会导致主库无法写入，切主前务必确认
权限账号要配合限制，否则形同虚设
即使开了 super_read_only，如果应用或 DBA 使用的账号本身有 SUPER 权限，且该账号被允许连接从库，那它仍可能通过其他方式绕过（比如用 mysqladmin flush-logs 触发某些副作用）。更稳妥的做法是：从库只授权最小必要权限。
- 禁止给从库账号授予
SUPER、REPLICATION CLIENT（除非真需要查复制状态）、SHUTDOWN等高危权限 - 应用账号统一用
SELECT+EXECUTE（存过）即可，绝不要给INSERT/UPDATE/DELETE - DBA 登录从库应使用专用只读账号，而非共用 root；可用
CREATE USER 'ro_admin'@'%' IDENTIFIED BY 'xxx'; GRANT SELECT ON *.* TO 'ro_admin'@'%'; - 若用 ProxySQL 或中间件，可在路由层强制拦截写请求，作为双重保险
验证是否真被锁死：用真实账号测一遍
配置改完别急着上线，拿一个带 SUPER 权限的账号（比如 root）连从库，手动试几个典型写操作。这是最容易被跳过的步骤，但恰恰最能暴露配置漏洞。
执行以下命令，预期全部报错：
INSERT INTO test.t1 VALUES (1); UPDATE mysql.user SET password_expired='Y' WHERE user='root'; DROP TABLE IF EXISTS test.tmp; CREATE TABLE test.test_lock (id INT);
错误信息应类似：ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement。如果某条没报这个错，说明 super_read_only 没生效，或账号权限没被正确识别。
特别注意：MySQL 8.0.12+ 对 super_read_only 的校验更严格，但某些云厂商 RDS 可能屏蔽或阉割该变量，部署前务必实测。
