MySQL只读模式配置：避开那些“看似生效”的坑
给MySQL设置只读模式，听起来是个简单的操作，但实际操作中，不少朋友都踩过坑。最常见的就是：明明配了read_only=ON，怎么用root账号还是能往里写数据？这其实不是配置失败，而是对参数机制的理解有偏差。今天，我们就来把这事儿彻底捋清楚。
read_only=ON 为什么不能阻止 root 用户写入
这里有个关键认知需要明确：MySQL的 read_only 参数，本质上是个“针对普通用户的限制开关”。它对拥有 SUPER 权限的用户——比如大家最常用的root账号——是网开一面的。这不是Bug，而是MySQL特意留下的管理后门。
所以，你经常会遇到这样的场景：信心满满地执行了 SET GLOBAL read_only = ON;，然后用root登录一试，INSERT、UPDATE照样畅通无阻，瞬间怀疑人生。其实，问题出在权限上。
- 治本之策是回收权限：真想锁死root的写操作，就得动真格，把它的
SUPER权限拿掉：REVOKE SUPER ON *.* FROM 'root'@'%';。 - 生产环境的最佳实践：与其在root账号上纠结，不如创建专用的只读账号，并显式地只授予
SELECT权限。把安全建立在明确的授权上，远比依赖一个参数开关更可靠。 - 注意例外情况：即便对普通用户，
read_only也管不着临时表（CREATE TEMPORARY TABLE）和写入某些日志表（如mysql.general_log）这类系统级操作。
my.cnf 中设置 read_only 后不生效的典型原因
改配置文件、重启服务，一气呵成，结果一查状态：SELECT @@global.read_only; 返回的还是 OFF。这种“配置不生效”的问题，多半是下面几个环节出了岔子。
- 配置文件位置不对：首先确认参数是写在
[mysqld]这个段落下。要是错放到[client]或[mysql]里，那肯定是白忙活。 - 配置文件“打架”了：MySQL可能会读取多个配置文件。用命令
mysqld --help --verbose | grep "Default options"查一下加载顺序。经常出现/etc/my.cnf和/etc/mysql/mysql.conf.d/mysqld.cnf内容冲突，后者覆盖了前者。 - 启动参数“一票否决”：如果在启动命令行里用了
--read-only=OFF，它会直接覆盖配置文件里的设置，让ON的配置瞬间失效。 - 云服务的特殊限制：如果你用的是阿里云RDS、AWS RDS这类云数据库，那要注意了。它们通常禁止直接修改
read_only参数，必须通过云控制台提供的专门开关来操作，改配置文件是没用的。
read_only 和 super_read_only 的区别与配合使用
MySQL 5.7.8版本之后，引入了一个“大杀器”：super_read_only。顾名思义，它比 read_only 更狠，连拥有 SUPER 权限的用户（除了复制线程）的写操作也一并禁止。
- 启用顺序有讲究：正确的姿势是先设
read_only=ON，再设super_read_only=ON。如果顺序反了，后者可能会拒绝生效。 - 主从架构下的黄金组合：对于从库，最安全的做法是同时开启这两个参数。这样即使有人误操作把从库提升为主库，写操作依然会被拦住，避免了数据污染。
- 一个重要的连锁反应：一旦开启了
super_read_only，连执行SET GLOBAL read_only = OFF这个命令本身都会被拒绝。想调整？必须先把super_read_only关掉才行。 - 查看状态要全面：检查时别只看一个，用
SELECT @@global.read_only, @@global.super_read_only;把两个状态都拉出来看看，心里才有底。
只读模式下仍可能触发写操作的隐蔽场景
你以为开了只读就万事大吉了？有些操作表面是“读”，暗地里却可能“写”，这些隐蔽的路径才是真正的风险点。
- 函数和触发器的“后门”：像
SELECT ... INTO OUTFILE这种语句，本身不写表。但如果它查询的表上挂了触发器，或者调用的自定义函数里包含了写逻辑，就可能悄无声息地触发写入。 - 语句的“整体性”判断：
INSERT ... SELECT是一个完整的写入语句。即使SELECT部分是从只读库查数据，MySQL也会因为整个语句是INSERT而直接拒绝执行。 - 复制环境下的“语义”破坏：在启用二进制日志（
log_bin）且格式为STATEMENT时，一些非确定性函数（如NOW(),UUID()）在从库执行，可能导致数据不一致。虽然不报错，但已经违背了“只读”的数据一致性语义。 - 监控工具的“意外”写入：像pt-heartbeat这类监控工具，如果配置不当，拥有写权限，它在只读实例上执行就会失败。务必确保这类工具使用的连接账号只有
SELECT权限。
说到底，构建一个真正安全的只读环境，靠的是组合拳：严格的账号权限控制是基础，read_only 和 super_read_only 参数是加固的防线，再配合上读写账号的物理分离。单靠一个 read_only 参数，是防不住所有“旁门左道”的。
