grant操作未进binlog导致从库权限不同步，根本原因是mysql默认不记录mysql.user表变更：5.7及以前需显式开启log_bin且不忽略mysql库，8.0+虽默认记录但依赖log_bin=on且replicate_ignore_db不含mysql；必须用create user+grant组合，禁用直接修改mysql.user表。
GRANT 操作没进 binlog，从库根本收不到 —— 这不是配置漏了、也不是账号输错，而是权限变更压根没被复制。
主库执行了 GRANT，但从库查不到用户
典型信号：SELECT user,host FROM mysql.user 在主库有结果，从库返回空；SHOW GRANTS FOR 'u'@'h' 在从库报 ERROR 1141 (42000)。根本原因不是语句写错了，是 MySQL 默认不把 mysql.user 表的变更写入 binlog。
- MySQL 5.7 及更早版本：
GRANT默认不记 binlog，除非显式开启log_bin=ON且未忽略mysql库 - MySQL 8.0+：
GRANT默认记录，但前提是：log_bin=ON且replicate_ignore_db里没写mysql - GTID 模式下还要额外检查：
binlog_ignore_db是否也屏蔽了mysql
直接改 mysql.user 表会彻底破坏复制
用 INSERT INTO mysql.user 或 UPDATE mysql.user 手动加账号，看似快，实则危险：
- 不会触发权限重载，
FLUSH PRIVILEGES也救不回来 - binlog 事件格式异常，从库回放失败，
Slave_SQL_Running: No是大概率结果 - 即使侥幸同步过去，
mysql.user表结构或校验逻辑在不同版本间可能不兼容
必须用 CREATE USER + GRANT 组合，例如：
CREATE USER 'reporter'@'%' IDENTIFIED BY 'pwd'; GRANT SELECT ON db.* TO 'reporter'@'%';
GRANT 是原子性 DDL，能正确生成 binlog 事件，且自动触发权限重载，无需手动 FLUSH PRIVILEGES。
从库 replicate_ignore_db 常被无意识继承
最容易被忽略的一点：主库开了 log_bin，但从库的 replicate_ignore_db 配置里含 mysql —— 尤其当配置通过 Ansible 或容器模板批量下发时，mysql 库常被默认加入忽略列表。
- 检查方式：
SHOW SLAVE STATUS\G中看Replicate_Ignore_DB字段 - 验证是否生效：主库执行
GRANT后，运行SHOW BINLOG EVENTS IN 'mysql-bin.0000xx' LIMIT 10，确认能看到Write_rows_v1或Query类型的权限相关事件 - 8.0+ 建议显式配：
binlog_format=ROW+default_authentication_plugin=mysql_native_password，避免插件不兼容
延迟大时在从库执行 FLUSH PRIVILEGES 是临时手段
这不是修复同步问题的方法，只是紧急确认用的权宜之计：
- 仅限从库明显延迟、权限未即时生效时，手动刷一次内存权限
- 不能替代 binlog 同步机制，也不能解决根本缺失（比如
mysql库被忽略） - 频繁依赖这个操作，说明底层 binlog 配置仍有隐患
真正要盯住的，永远是那两个硬性条件：主库 log_bin=ON，从库 replicate_ignore_db 不含 mysql —— 其他所有操作，都建立在这之上。
