主从节点须分权管理:主库创建专用复制账号并仅授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 已开启。
解析 MySQL 8.0 的 DDL 脚本,并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景,导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理,每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 动态设置优先于重启:先
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,也得手动打开才算真正锁死。

















