show slave status 需要 replication client 权限，而非 replication slave 或 all privileges；该权限必须全局授予（on .），由高权限账号执行并配合 flush privileges 生效，否则会报 error 1227 或返回 null。
SHOW SLAVE STATUS 需要 REPLICATION CLIENT 权限，不是 REPLICATION SLAVE，也不是 ALL PRIVILEGES —— 这是绝大多数人第一次踩的坑。
为什么 GRANT REPLICATION SLAVE 不起作用？
REPLICATION SLAVE 是给从库 IO 线程用的，允许它连主库拉 binlog；而 SHOW SLAVE STATUS 是监控命令，属于“只读查看”行为，MySQL 内部校验的是 REPLICATION CLIENT 权限。
- 执行
GRANT REPLICATION SLAVE ON *.* TO 'u'@'%';后仍报ERROR 1227 (42501): Access denied，基本可以锁定权限类型错误 - 即使用户有
ALL PRIVILEGES（MySQL 8.0+），也不会自动包含REPLICATION CLIENT -
REPLICATION CLIENT和REPLICATION SLAVE可共存，但目的完全不重叠：一个看状态，一个做同步
正确授权语句与生效要点
必须由具备 GRANT OPTION 的账号（如 root）执行，且权限必须显式授予全局范围 ON *.*：
- 安全写法（限制内网）：
GRANT REPLICATION CLIENT ON *.* TO 'monitor'@'10.46.%'; - 最小化范围：不能写成
ON db1.*或ON *.* TO 'monitor'@'localhost'（如果连接来自代理或跳板机，host 必须匹配真实客户端 IP） - 执行后必须
FLUSH PRIVILEGES;—— 已存在的连接不会自动加载新权限，需重新登录 - 验证是否生效：
SHOW GRANTS FOR 'monitor'@'10.46.%';，确认输出中含REPLICATION CLIENT ON *.*
常见报错与直连排查建议
如果 SHOW SLAVE STATUS\G 返回空或报错，先排除非权限干扰：
-
ERROR 1227 (42501)：纯权限问题，99% 是缺REPLICATION CLIENT - 返回
NULL（无报错）：可能是用了--binary-as-hex参数、或通过 ProxySQL / MaxScale 等代理，它们有时会截断或误处理复制状态字段 - GTID 模式下也依赖该权限：从库启动时若需读取
@@global.gtid_executed，同样触发ERROR 1227 - 务必用目标用户直连 MySQL 实例测试：
mysql -u monitor -p -h 10.46.169.62 -e "SHOW SLAVE STATUS\G"
监控账号权限组合建议
单纯查主从还不够，实际监控常需配套权限。按最小化原则组合即可：
-
REPLICATION CLIENT：必需，用于SHOW SLAVE STATUS、SHOW MASTER STATUS、SHOW BINARY LOGS -
PROCESS：用于SHOW PROCESSLIST，观察复制线程是否卡住 -
SELECT：访问information_schema或performance_schema中的指标表（如复制延迟计算） - 不要加
SUPER、REPLICATION SLAVE或ALL PRIVILEGES—— 它们带来不必要的风险，且不解决根本问题
真正容易被忽略的是 host 匹配和 FLUSH PRIVILEGES 的强制性：权限不是“授完就生效”，而是“下次登录才加载”，而很多自动化脚本用的是长连接，改完权限却没重启连接，结果一直以为授权失败。
