REPLICATION SLAVE权限缺失是主因，必须显式授予且host严格匹配；仅授REPLICATION CLIENT或GRANT ALL无效，授权后须FLUSH PRIVILEGES，并验证CURRENT_USER()与账号host完全一致。
REPLICATION SLAVE 权限缺失是主因
复制账号报 Access denied; you need (at least one of) the SUPER or REPLICATION SLAVE privilege(s)，根本原因就是没给 REPLICATION SLAVE 权限。这个权限专供从库的 IO 线程连接主库、拉取 binlog 使用，不能用 SELECT 或 REPLICATION CLIENT 替代。
常见错误操作：
- 只执行
GRANT REPLICATION CLIENT ON *.* TO 'repl'@'%'—— 这只能查主库状态，无法启动复制 - 误以为
GRANT ALL PRIVILEGES就够了，但 MySQL 8.0+ 默认不包含REPLICATION SLAVE在ALL里 - 授权后漏掉
FLUSH PRIVILEGES，尤其在直接改mysql.user表后
host 匹配失败导致权限不生效
CURRENT_USER() 返回的账号是 'repl'@'192.168.1.10'，但你只建了 'repl'@'%'，而从库实际连的是 127.0.0.1 —— 这时 MySQL 会匹配到 'repl'@'localhost'（如果存在），而它的权限可能是空的。
验证方式：
- 登录后立刻执行
SELECT USER(), CURRENT_USER(); - 查所有同名用户：
SELECT Host, User FROM mysql.user WHERE User = 'repl'; - 确认生效权限：
SHOW GRANTS FOR 'repl'@'192.168.1.10';（注意 host 必须和CURRENT_USER()完全一致）
密码含特殊字符引发 CHANGE MASTER TO 解析失败
账号密码里有 @、/、: 等字符时，CHANGE MASTER TO MASTER_PASSWORD='xxx' 语句会被 MySQL 客户端提前截断或转义，导致认证失败，看起来像权限问题。
实操建议：
- 创建复制账号时，密码避开
@ / : \ ' " ` - 如果必须用特殊字符，改用配置文件方式传参：
CHANGE MASTER TO MASTER_PASSWORD = PASSWORD('xxx');（仅限旧版本）或改用 MySQL 8.0+ 的 caching_sha2_password 插件 + SSL 加密连接 - 测试连接：用
mysql -u repl -p -h master_ip手动连一次，看是否能登录成功
GTID 模式下还缺 SESSION_VARIABLES_ADMIN 权限
主库开启 gtid_mode=ON 后，从库执行 START SLAVE 时可能报错 ERROR 1227 (42000): Access denied; you need ... SESSION_VARIABLES_ADMIN —— 这不是复制账号权限不够，而是从库自身需要该权限来设置 gtid_next 等会话级变量。
解决方法：
- 在从库上给复制线程用的账号（即
MASTER_USER）额外加权限：GRANT SESSION_VARIABLES_ADMIN ON *.* TO 'repl'@'%'; - 或者更稳妥的做法：主从都用
--set-gtid-purged=OFF导出备份，避免 GTID 相关权限依赖 - 注意：这个权限只需在从库授，主库不需要
复制账号权限问题本质是“窄权限 + 精准匹配”，少一个字符、多一个空格、host 写错网段，都会让整个复制链路卡在第一步。别迷信 GRANT ALL，也别跳过 CURRENT_USER() 验证。
