read_only仅限制非super用户，super用户（如root）仍可写；需通过配置文件设置并重启生效；super_read_only更严格，连super用户也限制；只读模式允许select等只读操作，禁止insert/update等写操作。
设置 read_only 后为什么普通用户还是能写？
因为 read_only 只限制非 SUPER 权限的用户，root 或拥有 SUPER 权限的账号仍可执行写操作。这是设计使然，不是配置失败。
- 检查当前用户权限：
SELECT CURRENT_USER(), USER();，确认你用的是普通账号而非高权限账号 - 验证是否生效：
SHOW VARIABLES LIKE 'read_only';返回ON才算设对了 - 如果用的是 MySQL 8.0.12+，
read_only对SYSTEM USER（如复制线程）也生效，但不影响主从同步本身
如何让 read_only 在重启后依然有效
仅执行 SET GLOBAL read_only = ON; 是临时的，MySQL 重启就失效。必须写入配置文件才持久。
- 编辑
my.cnf或mysqld.cnf，在[mysqld]段落下添加：read_only = ON - 注意：不能写成
read_only = 1或read_only = true，MySQL 只认ON/OFF字符串 - 修改后需重启 MySQL（
systemctl restart mysqld），或用mysqladmin shutdown+ 手动启动 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）不开放配置文件修改，只能通过控制台或 API 设置，
SET GLOBAL通常被禁用
read_only 和 super_read_only 的区别在哪
super_read_only 是 MySQL 5.7.8+ 引入的增强开关，它比 read_only 更严格：不仅限制普通用户，还禁止 SUPER 用户写入（除非先关掉它）。
- 启用顺序有依赖：
super_read_only开启时会自动把read_only设为ON；但反过来不行 - 常见误操作：
SET GLOBAL super_read_only = ON;后，连root都无法关掉read_only，必须先关super_read_only - 生产环境建议优先用
super_read_only，避免因权限疏忽导致误写
只读模式下哪些操作仍被允许？哪些会报错？
read_only 不影响 DDL 查询或事务内只读语句，但任何修改数据或结构的操作都会被拦截。
- 允许：
SELECT、SHOW、EXPLAIN、BEGIN/START TRANSACTION（只要里面不写） - 拒绝并报错：
INSERT、UPDATE、DELETE、DROP TABLE、TRUNCATE，错误信息是：ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement - 特别注意：
CREATE TEMPORARY TABLE默认允许（除非显式禁用read_only的临时表例外），而LOCK TABLES在read_only下会被拒绝
真正容易被忽略的是：只读模式不阻止日志写入、不阻止 binlog 记录（如果是主库）、也不阻止从库 SQL 线程回放 relay log —— 它只拦客户端主动发起的写请求。
