MySQL从库连接主库只需REPLICATION SLAVE权限，因其专用于读取binlog和元信息，不涉及数据操作；授权必须用ON .、限定具体IP、8.0+需指定认证插件，禁用ALL、SELECT、REPLICATION CLIENT等冗余权限。
MySQL主从复制中，从库连接主库时使用的账号**只需 REPLICATION SLAVE 权限**，不需要 SELECT、ALL PRIVILEGES 或 root 级权限——这是最常被误配的安全隐患。
为什么只用 REPLICATION SLAVE？
该权限专为复制链路设计，仅允许：
- 读取主库的
binlog内容（通过DUMP协议） - 获取
SHOW MASTER STATUS和SHOW BINARY LOGS的元信息 - 不涉及任何表数据查询、修改或管理操作
赋予额外权限（比如 REPLICATION CLIENT 或 SUPER）既无必要，又扩大攻击面。MySQL 5.7+ 默认禁止非必要高危权限用于复制账号。
GRANT REPLICATION SLAVE ON *.* TO ... 的实操要点
执行授权时必须注意以下细节：
-
ON *.*是固定写法，不能缩小范围（如ON db1.*），否则 I/O 线程启动失败，报错：ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER, REPLICATION SLAVE privilege(s) for this operation - 主机名要精确匹配从库发起连接的 IP 或域名；用
'repl'@'%'虽方便但不推荐生产环境，应限定为具体从库 IP，例如'repl'@'192.168.8.11' - MySQL 8.0+ 使用缓存认证插件，需显式指定：
CREATE USER 'repl'@'192.168.8.11' IDENTIFIED WITH mysql_native_password BY 'pass123';
- 执行完
GRANT后必须FLUSH PRIVILEGES;（虽然多数情况下自动刷新，但显式调用更稳妥）
哪些权限是「多余甚至危险」的？
这些常见误操作会埋下风险：
-
GRANT ALL PRIVILEGES ON *.* TO ...：赋予 DROP/SHUTDOWN/FILE 等高危权限，一旦账号泄露，可直接删库或读取系统文件 -
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO ...：前者仅用于监控（如SHOW SLAVE STATUS），从库线程本身并不需要，纯属冗余 -
GRANT SELECT ON *.* TO ...：可能被误用于导出全量数据，违背最小权限原则 - 用
root账号做复制用户：违反权限隔离，且 MySQL 8.0 默认禁用root远程登录
真正关键的不是“能给多少”，而是“最少给什么”——只要 REPLICATION SLAVE + 正确的 host 限制 + 强密码，就能稳定跑通复制。其他权限都是干扰项，删掉反而更健壮。
