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 限制 + 强密码，就能稳定跑通复制。其他权限都是干扰项，删掉反而更健壮。
