需授予replication client权限才能执行show slave status；该权限必须全局授予（on .），且不能用all privileges或replication slave替代，授权后需flush privileges。
SHOW SLAVE STATUS 报错：ERROR 1227 或返回 NULL
直接执行 SHOW SLAVE STATUS\G 报错或返回空结果，基本可以确定是权限问题。MySQL 5.7+ 和 8.0 默认不给普通用户授予 REPLICATION CLIENT 权限，即使你给了 ALL PRIVILEGES，也不包含这个能力。
常见错误信息：ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER or REPLICATION CLIENT privilege(s) for this operation
- 先确认当前用户权限：
SHOW GRANTS FOR CURRENT_USER; - 若没看到
REPLICATION CLIENT ON *.*，就需要 DBA 或高权限账号补授权 - 不要用
GRANT ALL PRIVILEGES代替 —— MySQL 8.0 已移除隐式包含REPLICATION CLIENT的行为
只给查看权限，不给复制权限：GRANT REPLICATION CLIENT 而非 REPLICATION SLAVE
标题里提到“授予 REPLICATION SLAVE 权限”，但注意：REPLICATION SLAVE 是给从库 IO 线程用的（用于拉取 binlog），它本身**不能**让普通用户执行 SHOW SLAVE STATUS。真正需要的是 REPLICATION CLIENT。
-
REPLICATION CLIENT：允许执行SHOW MASTER STATUS、SHOW SLAVE STATUS、SHOW BINARY LOGS等监控类命令 -
REPLICATION SLAVE：允许从库连接主库并读取 binlog，通常只赋给同步专用账号（如'repl'@'10.46.169.62'） - 两者可共存，但目的完全不同；监控账号只需前者，无需后者
授权命令写法与生效要点
授权语句必须由具备 GRANT OPTION 的高权限账号（如 root）执行，且需显式指定 host：
- 给所有 IP 的用户授权：
GRANT REPLICATION CLIENT ON *.* TO 'monitor_user'@'%'; - 限制为内网某段更安全：
GRANT REPLICATION CLIENT ON *.* TO 'monitor_user'@'10.46.%'; - 执行后必须
FLUSH PRIVILEGES;，否则权限不会立即生效 - 用户下次登录才加载新权限 —— 已存在的连接不会自动更新权限上下文
容易被忽略的兼容性细节
在 MySQL 8.0+ 环境下，REPLICATION CLIENT 权限不再附带任何其他能力，也不再和 SUPER 绑定。这意味着：
- 即使你把
REPLICATION CLIENT和SELECT一起授给某个账号，它依然不能执行SHOW SLAVE STATUS—— 因为该命令要求权限必须在*.*全局范围，不能限定到某个库 - 使用代理（如 ProxySQL）或某些客户端开启
--binary-as-hex时，SHOW SLAVE STATUS可能异常返回 NULL，建议直连排查 - 如果从库开启了 GTID 模式，
REPLICATION CLIENT仍足够查看状态，不需要额外开 GTID 相关权限
最常踩的坑是：以为给了 REPLICATION SLAVE 就能查状态，或者误以为 ALL PRIVILEGES 自动覆盖监控类权限 —— 实际上这两者在现代 MySQL 中完全正交，缺一不可地按需授予。
