必须显式授予REPLICATION CLIENT ON .权限，因为SHOW SLAVE STATUS是状态查询命令，MySQL内部强制要求全局REPLICATION CLIENT权限，而REPLICATION SLAVE仅用于IO线程拉取binlog，不提供监控能力。
不能只给 REPLICATION SLAVE，必须显式授予 REPLICATION CLIENT 全局权限，否则 SHOW SLAVE STATUS 一定失败。
为什么 REPLICATION SLAVE 不行？
这是最常见的误解来源：REPLICATION SLAVE 是给从库的 IO 线程用的（比如 CHANGE MASTER TO 后拉取 binlog），它不包含任何监控能力。SHOW SLAVE STATUS 属于“查看状态”类命令，MySQL 内部强制要求执行者拥有 REPLICATION CLIENT 权限——且必须是全局范围（ON *.*）。
- 即使你给了
ALL PRIVILEGES，在 MySQL 8.0+ 中也不会自动包含REPLICATION CLIENT -
REPLICATION SLAVE和REPLICATION CLIENT可共存，但目的完全不同：前者用于复制连接，后者用于状态查询 - 报错
ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER or REPLICATION CLIENT privilege(s)就是典型信号
正确授权语句怎么写？
必须由具备 GRANT OPTION 的账号（如 root）执行，且不能省略 ON *.*：
GRANT REPLICATION CLIENT ON *.* TO 'monitor_user'@'%';
- 限制访问更安全：把
'%'换成具体网段，例如'10.46.%'或'192.168.1.0/24' - 不要用
IDENTIFIED BY在同一句里创建用户；先CREATE USER，再GRANT，逻辑更清晰 - 执行后必须立刻
FLUSH PRIVILEGES;，否则已建立的连接仍无权限
验证权限是否生效？
切到目标用户连接后，直接运行：
SHOW GRANTS FOR CURRENT_USER;
- 输出里必须明确看到
REPLICATION CLIENT ON *.*，而不是REPLICATION SLAVE或其他变体 - 如果看到的是
REPLICATION CLIENT ON `db_name`.*（带具体库名），说明授错范围了——该权限只允许全局授予 - 直连测试：避免通过 ProxySQL、MaxScale 等中间件，它们可能干扰权限上下文或二进制协议解析
容易被忽略的兼容性细节
MySQL 8.0+ 对权限管控更严格，几个硬性约束：
-
REPLICATION CLIENT不再隐式携带SUPER或任何其他权限，哪怕和SELECT一起授予也不行 - 权限必须在
*.*级别，GRANT REPLICATION CLIENT ON `mydb`.* TO ...无效 - 已有连接不会自动更新权限，必须重新登录；应用端若长连接未重连，会持续报错
- 某些客户端（如旧版 mysql CLI 加
--binary-as-hex）可能让SHOW SLAVE STATUS返回NULL，建议用标准方式直连验证
真正要查从库状态，就只认 REPLICATION CLIENT ON *.* 这一条路，多一个字、少一个点都不行。
