REPLICATION SLAVE权限是硬性准入门槛，因从库IO线程通过复制协议请求binlog事件而非执行SQL，MySQL内核强制校验该权限，缺之则拒绝连接并报错。
为什么REPLICATION SLAVE权限不能省
从库IO线程连接主库时，不是以“用户身份”执行SQL，而是以复制协议请求binlog事件。MySQL内核会校验该连接账号是否具备REPLICATION SLAVE权限——没有就直接拒绝，报错ERROR 1236 (HY000): Could not open log file或Access denied; you need ... REPLICATION SLAVE privilege(s)。给SELECT或REPLICATION CLIENT都没用，这是硬性准入门槛。
创建账号时host和密码的实操陷阱
常见错误是写'repl'@'%'：MySQL 8.0+默认用caching_sha2_password插件，而%无法匹配该插件的认证流程，导致CHANGE MASTER TO连不上；生产环境也不该放行全网。
- host必须写从库真实出口IP或子网段，例如
'repl'@'192.168.5.20'或'repl'@'192.168.5.%' - 密码避免含
@、/、空格等特殊字符，否则CHANGE MASTER TO MASTER_PASSWORD='xxx'语句会因SQL解析失败 - MySQL 8.0+需显式禁用密码过期：
CREATE USER 'repl'@'192.168.5.20' IDENTIFIED BY 'p' PASSWORD EXPIRE NEVER，否则default_password_lifetime=360会让账号静默失效
授权后必须回收多余权限
执行GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.5.20'后，MySQL会自动附带USAGE权限，但不会自动清除其他历史权限。如果这个账号之前被授过ALL PRIVILEGES，它就能删库、改配置——这完全违背最小权限原则。
务必补上清理命令：
REVOKE ALL PRIVILEGES ON *.* FROM 'repl'@'192.168.5.20'; FLUSH PRIVILEGES;
再用SHOW GRANTS FOR 'repl'@'192.168.5.20'确认输出只剩一行GRANT REPLICATION SLAVE ON *.* TO `repl`@`192.168.5.20`。
GTID模式下要不要加REPLICATION CLIENT
只在从库需要主动查询主库GTID状态（比如监控脚本调用SELECT @@global.gtid_executed）时才需要。应用账号、同步账号本身都不需要它。加了反而危险——REPLICATION CLIENT能执行STOP SLAVE、RESET MASTER等破坏性命令，一旦泄露或误用，整条复制链路就断了。
真正要它的，只有DBA本地维护账号或mysqld_exporter这类专用监控工具账号，且必须限定host、禁用远程登录、定期轮换密码。
