复制账号只需 REPLICATION SLAVE 权限，且必须限定来源 IP、强密码并确保网络与日志配置正确；其他权限既不必要又增加风险。
复制账号只需 REPLICATION SLAVE 权限，别多给也别少给
MySQL 主从复制中，从库连接主库时使用的账号，**唯一必需的权限就是 REPLICATION SLAVE**。它专用于让从库读取主库的二进制日志（binlog），不涉及数据查询、修改或管理操作。
常见错误是顺手给 SELECT、ALL PRIVILEGES 甚至 GRANT OPTION——这既无必要，又增加安全风险。生产环境尤其要避免：
-
REPLICATION SLAVE已足够启动 IO 线程拉取日志 - 不需要
SELECT：从库同步靠 relay log 回放，不走主库 SELECT 查询 - 禁止
SUPER或SHUTDOWN等高危权限 - 若后续启用 GTID 复制，仍无需额外授权，
REPLICATION SLAVE依然够用
创建账号时 'repl'@'%' 要收紧，别留后门
开发环境图省事写 'repl'@'%'，上线必须改掉。% 允许任意 IP 连接，等于把 binlog 通道暴露在公网。
实操建议：
- 明确指定从库 IP，例如
'repl'@'192.168.5.22'（单从库）或'repl'@'192.168.5.%'（同网段多从库） - 避免使用
'repl'@'localhost'：从库通常远程连接，localhost 仅限本地 socket，无法生效 - 密码必须强口令，且避免明文硬编码在
CHANGE MASTER TO语句里（MySQL 8.0+ 支持使用MASTER_USER+ 密码文件方式增强安全性） - 执行完记得
FLUSH PRIVILEGES，否则权限不生效——这个步骤常被跳过，导致Access denied报错
SHOW MASTER STATUS 不是授权动作，但它是同步起点
很多人误以为授权完就能直接 START SLAVE，结果卡在 Slave_IO_Running: No。根本原因常是没获取正确的同步起点。
SHOW MASTER STATUS 返回的 File 和 Position 值，是 CHANGE MASTER TO 中 MASTER_LOG_FILE 和 MASTER_LOG_POS 的唯一合法来源。
注意：
