MySQL 8.0 中 BINLOG_ADMIN 权限必须全局授予，即 GRANT BINLOG_ADMIN ON .；不可限定库表，否则报错；它支持 FLUSH/PURGE/SHOW BINLOG 相关操作，但不提供远程拉取 binlog 或读取磁盘文件能力。
GRANT BINLOG_ADMIN ON *.* 是唯一正确写法
MySQL 8.0 中，BINLOG_ADMIN 是专用于二进制日志管理的动态权限，不能限定到库或表，必须用 ON *.* 全局授予。写成 ON mysql.* 或 ON `binlog_db`.* 都会报错：ERROR 1044 (42000): Access denied for user —— 权限系统直接拒绝解析。
常见错误是误以为它和 SELECT 权限类似可按对象粒度控制，其实它只作用于服务器级 binlog 操作，比如 FLUSH BINARY LOGS、PURGE BINARY LOGS、SHOW BINLOG EVENTS 等命令。
- 必须由高权限账号（如
root或已具备BINLOG_ADMIN的用户）执行 - 用户需已存在；若不存在，先
CREATE USER 'audit'@'192.168.10.%'，再GRANT BINLOG_ADMIN ON *.* TO 'audit'@'192.168.10.%' -
FLUSH PRIVILEGES在 8.0+ 多数场景下非强制，但建议保留，避免缓存延迟导致权限未生效
BINLOG_ADMIN 能做什么，不能做什么
BINLOG_ADMIN 允许执行以下操作：
-
FLUSH BINARY LOGS（滚动当前 binlog 文件） -
PURGE BINARY LOGS BEFORE '2026-09-01 00:00:00'（清理过期日志） -
SHOW BINLOG EVENTS IN 'binlog.000012'（查看指定文件事件内容） -
SHOW MASTER STATUS和SHOW BINARY LOGS（这些其实只需要REPLICATION CLIENT，但BINLOG_ADMIN自动隐含该权限）
但它**不提供**：
- 读取磁盘上
mysql-bin.000012文件内容的能力（那是操作系统层权限） - 远程拉取 binlog 流的能力（需要
REPLICATION SLAVE配合mysqlbinlog --read-from-remote-server） - 查看或修改 GTID_EXECUTED 等复制元数据以外的复制状态（仍依赖
REPLICATION CLIENT）
和 REPLICATION CLIENT、REPLICATION SLAVE 的关系
三者职责不同，常需组合使用：
-
REPLICATION CLIENT：查主从位置、日志列表、GTID 状态 ——SHOW MASTER STATUS、SHOW SLAVE STATUS所需 -
REPLICATION SLAVE：支持 binlog 流式读取协议 ——mysqlbinlog --read-from-remote-server必须，MHA 切换也依赖它 -
BINLOG_ADMIN：管理 binlog 生命周期与内容查看 ——PURGE、SHOW BINLOG EVENTS所需
单独授 BINLOG_ADMIN 后，用户仍无法执行 mysqlbinlog --read-from-remote-server，会报错：Access denied; you need (at least one of) the REPLICATION SLAVE privilege(s)。这是协议级限制，不是权限遗漏。
生产环境授权要避开的坑
最容易被忽略的是 host 范围和网络连通性：
- 不要用
'audit'@'%'开放所有来源，应限定为具体网段，例如'audit'@'192.168.10.%' - 确认 MySQL 配置中
bind-address不是127.0.0.1，否则外部无法连接 - Linux 防火墙（如
ufw或firewalld）必须放行 3306 端口 - 如果启用了
skip-name-resolve，DNS 解析失败时会 fallback 到localhost，导致权限匹配失败 —— 建议用 IP 而非域名创建用户
真正麻烦的不是授权语句本身，而是权限生效后，用户实际连接时的 host 匹配是否与 GRANT 完全一致。最稳的方式是登录后立刻执行 SELECT USER(), CURRENT_USER();，比对返回值。
