在MySQL主从复制架构中，从库通常希望通过read_only参数防止误写入。但不少运维人员遇到过这样的情况：已经在配置文件中设置了read_only=1，重启实例后却发现依然可以执行insert或update。要弄清这个问题，必须先理解MySQL配置体系的加载逻辑以及各类优先级规则。
一、read_only参数的基本作用与限制
read_only是MySQL服务端的一个系统变量，当设置为1时，普通用户（不具备SUPER或SUPER_READ_ONLY权限）将无法执行任何写操作，包括insert、update、delete以及DDL语句。该参数主要用于保护从库数据不被人为修改，从而保证复制链路的一致性。
需要注意的是，read_only并不能阻止拥有SUPER权限的账户进行写入。很多初学者在测试时用root账号登录从库，执行一条insert成功，就误以为配置文件没有生效。实际上root默认拥有SUPER权限，不受该参数约束。因此在验证时，应当创建一个普通业务账号来测试写操作，而不是直接使用管理员账户。
二、配置文件生效优先级导致只读失效
MySQL在启动时会按固定顺序读取配置，不同来源的同一个参数值会相互覆盖。优先级从高到低大致为：命令行参数、环境变量、配置文件（按读取顺序后者覆盖前者）、编译默认值。如果在启动脚本中写了mysqld --read_only=0，那么配置文件中无论怎么写都不会生效。
配置文件本身也有段（section）概念，例如[mysqld]、[server]、[mysqld_safe]等。MySQL会依次解析这些段，如果在靠后的段中再次出现了read_only，则后面的值会覆盖前面的。此外，若系统使用了多个my.cnf（如/etc/my.cnf、/etc/mysql/my.cnf、数据目录下的my.cnf），后读取文件中的同名参数也会覆盖先前的设置。下面是一段典型的错误配置示例：
[mysqld] read_only=1 [mysqld_safe] read_only=0
上述配置中，虽然[mysqld]段开启了只读，但[mysqld_safe]段将其关闭，最终运行时值可能为0。要避免此类问题，应将只读参数统一放在[mysqld]段，并确认没有其他段或启动命令对其进行覆盖。
三、如何检查配置文件的生效路径与优先级
排查配置是否生效，第一步是查看运行时实际值。在MySQL客户端中执行如下语句：
show variables like 'read_only'; show variables like 'super_read_only';
如果查询结果并非预期，就需要确认MySQL到底读取了哪些配置文件。可以通过下面的命令列出默认加载顺序：
mysqld --help --verbose | grep -A 1 'Default options'
该命令会输出类似“/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf”的路径列表。你可以依次检查这些文件，搜索read_only字符串，确认是否存在多处定义。同时也要注意，有些发行版会通过systemd的Environment或ExecStart参数注入命令行选项，这类方式优先级最高，使用systemctl cat mysqld可查看相关单元配置。
四、其他常见误区与处理建议
除了优先级覆盖，还有几个容易忽略的点。其一是super_read_only参数，当该值设为1时，即便有SUPER权限的用户也无法写入，但它本身依赖read_only。如果只设了super_read_only而未显式设read_only，某些旧版本行为可能不符合直觉。其二是动态修改与持久化混淆，在会话中执行set global read_only=1仅对当前运行实例有效，重启后依旧以配置文件为准。
建议在部署从库时，采用统一的配置管理工具分发my.cnf，避免手工在多台机器上零散修改。同时在监控中增加一项校验：定期比对show variables中的read_only与配置模板中的期望值，一旦发现偏差就触发告警。这样可以在参数被意外覆盖时快速发现，而不是等到数据不一致才排查。
五、验证配置的完整示例
下面是一个简单的排查与验证流程代码，可用于脚本化检测：
#!/bin/bash
# 检查运行值
val=$(mysql -N -e "show variables like 'read_only'" | awk '{print $2}')
if [ "$val" != "ON" ]; then
echo "read_only未生效，当前值: $val"
# 输出配置文件读取顺序
mysqld --help --verbose 2>/dev/null | grep 'Default options'
else
echo "read_only已生效"
fi
通过将此类检查纳入日常巡检，可以有效规避配置文件优先级引发的只读失效问题，保障从库的数据安全性与架构稳定性。