MySQL 从库设为 read_only=ON 是否真能防误删？

直接给出结论：这个设置能有效拦截大多数“手滑”导致的误操作，但它并非万无一失的绝对屏障。具体而言，它可以阻止普通账号执行 DELETE、UPDATE、INSERT 及 DROP 等 DML 和 DDL 操作。然而，这里存在一个关键限制：执行操作的用户不能是具有 super 或 SYSTEM_VARIABLES_ADMIN 等高权限的账号。一旦此类高权限账号登录，read_only 的防护机制就会被绕过，写入操作仍可正常执行。

这也解释了运维中常遇到的两个“异常”情况：明明从库已设置 read_only=ON，但使用 root 账号登录后依然能成功删除表；或是在主从切换后，从库未能自动恢复只读状态，导致后续数据写入造成数据污染。

要规避这些风险，必须关注以下几个关键细节：

• read_only 是一个会话级变量，必须设置为全局生效才能起作用：SET GLOBAL read_only = ON;
• 仅使用 SET 命令是临时性的，MySQL 重启后会失效。因此，务必在配置文件（通常是 my.cnf 或 my.ini）的 [mysqld] 段落中永久添加一行：read_only = ON。
• 如果部署了 MGR（MySQL 组复制）或采用了基于 GTID 的自动故障转移方案，则需要格外注意。此时，仅配置 read_only 是不够的，必须确认 super_read_only=ON 也已启用，否则高权限用户仍可进行写入。

为什么 super_read_only 比 read_only 更关键？

简而言之，read_only 防范的是“普通用户”，而 super_read_only 防范的是“管理员”。前者仅限制非超级用户，后者则连 root 这样的超级用户也一并锁定——只要它被启用，连执行 SET GLOBAL read_only = OFF 这样的命令都会失败，除非你先关闭 super_read_only 本身。

这个特性在哪些场景下是必需的呢？任何你不希望“有人登录后随意修改”的环境都应考虑启用。例如生产环境的从库、专用的备份节点、用于审计的数据副本等。

启用时，顺序有严格的依赖关系，切勿弄错：

• 必须先开启 read_only，然后才能开启 super_read_only。如果顺序颠倒，后者会直接拒绝开启。
• 关闭时的顺序则相反：先执行 SET GLOBAL super_read_only = OFF，然后才能关闭 read_only。
• 需要注意的是，super_read_only 变量从 MySQL 5.7.20 版本才开始支持。对于更早的版本，只能依靠严格的权限控制和额外的监控告警来弥补这一不足。

哪些操作不受 read_only 限制？容易被忽略的写入点

即使开启了 read_only，数据库也并非完全“只读”。有几类操作仍可能悄悄写入数据，导致从库数据发生意外偏移，需要高度警惕：

• 执行某些管理命令，例如 FLUSH LOGS、RESET MASTER。这些命令虽不直接修改业务表，但会破坏二进制日志结构，严重影响主从复制的一致性。
• 创建或删除临时表：CREATE TEMPORARY TABLE 语句不受 read_only 的限制。
• 修改系统表，比如 mysql.user。如果登录的账号拥有对系统表的 UPDATE 权限，操作依然可以成功。
• 调用含有写逻辑的存储函数。如果函数内部包含了 INSERT 等操作，且函数定义时未使用 READS SQL DATA 等限定符声明为只读，那么调用它就可能产生写入。

因此，仅依靠一个 read_only 参数就想确保从库安全显然是不够的。必须结合“最小权限原则”来使用：专门为从库创建连接账号，并且只授予 SELECT、REPLICATION CLIENT、PROCESS 等必要的只读或监控权限，坚决移除所有 DML（数据操作语言）和 DCL（数据控制语言）权限。

验证从库是否真正只读：别只信 SHOW VARIABLES

通过 SHOW VARIABLES LIKE 'read_only' 查看到返回值为 ON，这当然是个积极信号，但它绝不等于绝对安全。实际情况可能更复杂：该设置可能被某个临时运维脚本关闭后忘记重新打开；也可能是账号权限未严格限制，留下了漏洞。

那么，如何可靠地验证从库只读状态呢？经验表明，最“直接”的方法往往最有效：

• 使用实际的、权限较低的业务账号登录，尝试执行一条写操作，例如：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 的错误提示。
• 再用 root 这类高权限账号登录，尝试执行：SET GLOBAL read_only = OFF;。如果此命令执行成功，则直接证明 super_read_only 未开启，防护存在缺口。
• 检查当前活跃连接是否有非只读行为：可以查询 performance_schema.events_statements_summary_by_user 系统表，观察近期是否有 UPDATE 或 DELETE 等语句的执行记录。

真正棘手的是那种“半只读”的混沌状态：配置文件中明明设置了参数，但 MySQL 启动时因权限或路径问题未能成功加载；或者参数被 systemd 服务脚本、其他自动化部署工具意外覆盖。因此，每次进行相关配置变更后，最稳妥的做法是亲自登录数据库，执行一遍上述的写操作测试进行验证，确保防护措施切实生效。