super_read_only拦不住复制账号写入，因为其设计本就不限制sql线程——该线程是mysql内部服务线程，非用户会话，拥有绕过权限检查的特权，确保主从同步正常运行。
super_read_only 为什么拦不住复制账号的写入
因为 super_read_only 的设计本就不限制 SQL 线程自身执行 relay log 中的语句——它只限制「用户发起的写操作」，而复制线程（SQL_THREAD）不是用户会话，它是 MySQL 内部服务线程，拥有绕过该开关的特权。
这是机制，不是漏洞。MySQL 必须允许从库重放主库的变更，否则主从同步彻底失效。所以哪怕 super_read_only = ON，只要 Slave_SQL_Running: Yes，SQL 线程就能正常执行 INSERT/UPDATE/DROP 等操作。
-
super_read_only拦的是mysql -u root -p这类连接后手动执行的 DML/DDL - 复制线程使用的权限是系统内建上下文，不走用户权限检查路径，也不受
read_only或super_read_only约束 - 即使你用
REVOKE收回了复制账号（如repl用户）的所有权限，只要CHANGE MASTER TO配置正确且 IO 线程能拉日志，SQL 线程照样工作
哪些账号写入会被 super_read_only 拦住
所有显式由客户端发起、经由用户连接执行的写操作都会被拒绝，典型包括：
- 运维用
root登录从库后执行DELETE FROM orders WHERE ... - 应用误连从库，用带
INSERT权限的账号执行写语句 - 监控脚本用高权限账号连库并执行
CREATE TABLE heartbeat_test - DBA 手动在从库上建临时表、调用存储过程、安装插件等
错误信息统一为：ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement。注意：这个报错只出现在用户会话中，不会出现在 SHOW SLAVE STATUS 输出里。
为什么 SHOW GRANTS 看不到复制账号的写权限却仍能写
因为复制账号（比如 'repl'@'10.0.1.%'）本身不需要被授予 INSERT 或 DROP 权限——它只靠 REPLICATION SLAVE 权限启动 IO 线程；而真正执行写入的是 SQL 线程，它不依赖该账号的权限集。
-
REPLICATION SLAVE权限仅用于建立主从连接，和写入无关 - SQL 线程运行在 mysqld 进程内部，以系统身份操作数据字典和存储引擎，权限模型完全不同
- 你可以用
SELECT CURRENT_USER()验证：复制线程执行语句时，CURRENT_USER()返回的是空或NULL，不是repl@%
真正需要防的不是复制账号，而是误连的用户账号
生产环境中最危险的不是复制本身，而是人连错了库、用了错账号、脚本没切环境。这时候 super_read_only 才起作用。
- 务必确认应用、BI 工具、定时任务连接字符串指向的是主库，而不是从库 IP
- 从库账号必须最小化授权：
GRANT SELECT, REPLICATION CLIENT ON *.* TO 'readonly_app'@'%'，禁用SUPER、FILE、PROCESS等高危权限 - 云 RDS 用户要注意：部分厂商把
super_read_only封装成控制台开关，动态 SET 可能被忽略，得走管控面配置
别指望参数自动兜底。复制线程的写入能力是 MySQL 主从架构的根基，关不掉，也不该关；你要盯紧的，永远是那些带着 root 或 ALL PRIVILEGES 连进来的活人和脚本。
