主从节点须分权管理：主库创建专用复制账号并仅授REPLICATION SLAVE权限、精确限制IP；从库启用read_only与super_read_only双锁机制，并按角色分离业务账号权限，确保写操作被严格阻断。
主从节点必须分权管理，不能共用同一套账号权限体系。主库要放行写操作和复制授权，从库则必须阻断写入通道并收缩查询范围——这是防止数据漂移和越权访问的底线。
主库上创建专用复制账号并限制连接来源
复制账号不是普通业务账号，它只服务于从库的 I/O 线程，必须最小化权限和网络暴露面。
-
REPLICATION SLAVE是唯一必需权限，FILE权限在旧版本中可能被误加，MySQL 8.0+ 已不需 - 主机名不能用
'%'，应精确到从库 IP，例如'repl'@'192.168.5.22'；若有多从库，逐个授权，避免宽泛匹配 - 密码须满足当前 MySQL 的密码策略（如
validate_password.length），否则CREATE USER会静默失败 - 执行后务必运行
FLUSH PRIVILEGES;，否则权限不会立即生效
示例：
CREATE USER 'repl'@'192.168.5.22' IDENTIFIED BY 'R3pl!2026';<br>GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.5.22';<br>FLUSH PRIVILEGES;
从库启用 read_only + super_read_only 双锁机制
仅设 read_only = 1 不够，SUPER 用户仍可写入；而 super_read_only 在 MySQL 5.7+ 才可用，且依赖 read_only 已开启。
- 动态设置优先于重启：先
SET GLOBAL read_only = ON;，再SET GLOBAL super_read_only = ON; - 检查是否生效必须用
SELECT @@read_only, @@super_read_only;，返回两个1才算闭环 - 若 MySQL 版本是 5.6 或更早，
super_read_only不存在，此时必须严格管控 SUPER 账号登录从库的行为 - 注意：SQL 线程自身写入不受影响，这是设计使然，无需干预
按角色建业务账号，主从分离授权粒度
报表用户、ETL 工具、监控脚本等，不应拥有跨库或跨实例的通用权限。主库可授写权限，从库只授 SELECT，且限定库表。
- 从库账号示例：
CREATE USER 'reporter'@'10.0.3.%' IDENTIFIED BY 'r3p0rt_2026';，然后GRANT SELECT ON `sales`.* TO 'reporter'@'10.0.3.%'; - 主库对应账号可额外加
INSERT, UPDATE, DELETE，但禁止授予GRANT OPTION或SUPER -
GRANT语句中的库名必须用反引号包裹（如`sales`），否则含下划线或短横的库名会报语法错 - 权限变更后，应用连接池若长连接未断开，旧权限仍有效，需主动 kill 连接或等超时
验证权限隔离是否真实生效
配置写完不等于跑通，常见失效点藏在细节里：变量作用域、配置加载顺序、版本兼容性、甚至 SELinux 上下文。
- 在从库用
reporter账号执行INSERT INTO t VALUES (1);，应明确报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement - 用
repl账号尝试连主库执行DROP DATABASE test;，应因权限不足拒绝，而非连接失败 - 检查
SHOW GRANTS FOR 'repl'@'192.168.5.22';输出是否只含REPLICATION SLAVE，无多余权限 - 若从库启用了
skip-grant-tables或配置文件中存在多个[mysqld]段，可能导致read_only未被读取
最易忽略的是：super_read_only 在 MySQL 8.0.26+ 默认为 OFF，即使 read_only 为 ON，也得手动打开才算真正锁死。
