read_only = ON 不能阻止 SUPER 权限用户写入，是 MySQL 的设计行为；真正全局只读必须启用 super_read_only = ON，且需按序配置、持久化并配合权限收紧与云环境适配。
只设 read_only = ON 不能拦住 SUPER 权限用户，这是 MySQL 的设计行为，不是配置失败。
为什么 read_only = ON 后 root 还能写入？
MySQL 的 read_only 参数默认只限制非 SUPER 权限用户。root、DBA 账号、监控脚本常用账号大多自带 SUPER 权限，可直接绕过该限制——包括 DROP TABLE、CREATE FUNCTION、ANALYZE TABLE（MySQL 8.0+ 对系统表也生效），甚至 FLUSH STATUS 都能成功执行。
典型现象：
- 执行
SET GLOBAL read_only = ON后，用root@localhost登录仍能删表 - BI 工具或健康检查脚本连从库顺手执行
INSERT INTO health_check，污染数据 -
SHOW VARIABLES LIKE 'read_only'返回ON，但写操作没被拦住
super_read_only = ON 才是真正兜底的开关
super_read_only 在 MySQL 5.7.8+ 引入，开启后连 SUPER 用户也无法执行任何写操作，包括：
-
INSERT/UPDATE/DELETE -
CREATE EVENT、INSTALL PLUGIN -
SET GLOBAL修改变量本身（如SET GLOBAL max_connections = 1000）
但它和 read_only 有强依赖关系：
-
super_read_only = ON会自动把read_only设为ON -
read_only = OFF会强制把super_read_only设为OFF - 动态设置必须先
SET GLOBAL read_only = ON，再SET GLOBAL super_read_only = ON；反过来直接报ERROR 1290 - 配置文件里
super_read_only = ON必须写在read_only = ON后面，否则 MySQL 启动失败
即使两个参数都开了，仍可能“看起来只读、实际可写”
原因不全是配置问题，得排查这些隐性干扰项：
- 云 RDS（如阿里云、腾讯云）可能屏蔽
super_read_only参数，配置了也无效果——得查控制台文档或联系支持确认是否开放 - 磁盘满到 ≥95% 时，MySQL 会自动静默触发保护机制，把
read_only设为ON，错误提示一模一样，但你查配置文件什么都没改：df -h看/var/lib/mysql所在分区 -
FLUSH LOGS、RESET MASTER不改业务表，但破坏复制一致性，super_read_only不拦 - 账号有
UPDATE权限时，仍可修改mysql.user等系统表 - 含写逻辑的存储函数（未加
READS SQL DATA限定）会被调用并执行写操作
验证只读是否真生效，别只信 SHOW VARIABLES
SHOW VARIABLES 只反映变量值，不反映权限是否卡死。必须用实际业务账号登录实测：
- 用应用连接用的账号（比如
app_user）执行：INSERT INTO test_table VALUES (1)，应立刻报ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement - 用运维常用账号（比如
dba_admin）执行：DROP TABLE tmp_log，也应报错——否则说明super_read_only没生效或账号仍有SUPER - 检查账号权限：
SELECT CURRENT_USER(), SUPER_PRIV FROM mysql.user WHERE User=CURRENT_USER();，确认没继承SUPER
最易忽略的是：主从切换后，原从库变主库，但 read_only 和 super_read_only 不会自动关闭——新主库就变成“假性只读”，应用写请求全失败。自动化切换工具必须包含 post-failover 步骤来关掉这两个变量。
