MySQL 8.4原生只读节点必须同时启用read_only和super_read_only，因为read_only仅限制非SUPER用户，而super_read_only才强制拦截所有用户（含DBA、备份工具等）的写操作，二者联动且后者为真正兜底机制。
MySQL 8.4 的原生只读节点，必须同时启用 read_only 和 super_read_only，否则任何拥有 SUPER 权限的账号（包括 DBA 自己）都能绕过只读限制写入数据。
为什么只设 read_only=ON 不够用
MySQL 的 read_only 本质是“对非 SUPER 用户生效”的开关。它不拦 DBA、备份工具、监控脚本、甚至某些中间件内置账户——只要它们带 SUPER 权限，INSERT/UPDATE/DROP 全部照常执行。你看到从库没被写坏，往往只是因为没人用高权限账号连上去试，而不是它真安全。
典型误判场景：
- 运维同学用
root连从库查问题，顺手UPDATE config SET value='test'→ 成功写入 - 备份脚本带
--single-transaction+SUPER权限，在从库上建临时表或改系统变量 → 触发复制异常 -
mysqldump --all-databases在从库执行时，遇到CREATE DATABASE报错但继续跑，部分库 dump 失败却无感知
super_read_only=ON 才是真正兜底的开关
super_read_only 是 MySQL 5.7 引入、8.0+ 稳定支持的硬性拦截机制：一旦开启，所有用户（含 SUPER）都无法执行写操作，除非先关闭它。它和 read_only 是联动的——设 super_read_only=ON 会自动把 read_only 拉成 ON；但反过来不行。
实操建议：
- 在从库
my.cnf的[mysqld]段里加两行：read_only = ON<br>super_read_only = ON
- 动态生效（无需重启）：
SET GLOBAL read_only = ON;SET GLOBAL super_read_only = ON; - 验证是否生效：
SELECT @@read_only, @@super_read_only;→ 两个都得是1SHOW VARIABLES LIKE '%read_only%';→ 确认没有遗漏项
别漏掉复制线程和临时表这两个例外
super_read_only 虽严，但有两个设计上的“放行口”：复制线程（sql_thread）和临时表（CREATE TEMPORARY TABLE）。这是合理的，否则主从同步就断了，有些查询也跑不动。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
但这也意味着：
- 如果你在从库上手动
START SLAVE，它依然能写 relay log 和 apply 日志 → 这是正常行为，不用干预 - 普通用户仍可建临时表并写入：
CREATE TEMPORARY TABLE tmp_log AS SELECT * FROM error_log LIMIT 100;→ 不报错
所以敏感报表逻辑若依赖临时表，得额外审计其内容，不能默认“只读=绝对干净” - 某些 ORM 或连接池会在初始化时自动建临时表（如 Hibernate 的 schema validation），需确认是否触发误告警
检查只读状态必须用 SELECT @@read_only，别信 SHOW SLAVE STATUS
很多人习惯看 SHOW SLAVE STATUS\G 里的 Seconds_Behind_Master 或 Slave_IO_Running，但这完全不反映只读状态。一个从库可能复制延迟为 0、IO/SQL 全 running，但 read_only 是 OFF —— 它就是个裸奔的可写实例。
Keepalived、Zabbix、Prometheus 监控脚本里，检测只读的唯一可靠方式是：mysql -Nse "SELECT @@read_only AND @@super_read_only" → 返回 1 才算真正只读。
最容易被忽略的一点：MySQL 8.4 默认开启 enforce_gtid_consistency=ON，而 super_read_only=ON 在 GTID 模式下对 sql_thread 的保护更稳定；但如果从库曾手动执行过 SET GTID_NEXT 类操作，可能残留不一致状态，上线前务必 RESET SLAVE ALL 并重拉一次复制。
