grant语句未进binlog导致从库无权限，根本原因是mysql默认不记录权限变更：5.7及以前默认关闭，8.0+需log_bin=on且未配置replicate_ignore_db=mysql；直接操作mysql.user表更会引发复制失败。
GRANT 语句没进 binlog，从库压根不知道有这个用户
MySQL 主从默认不把 GRANT 这类权限变更写进 binlog —— 尤其是 5.7 及更早版本，默认关闭该行为；8.0+ 虽默认开启，但前提是 log_bin 必须启用，且不能配置 replicate_ignore_db=mysql。一旦跳过 mysql 库，GRANT 就不会同步过去。
典型现象包括：SELECT user,host FROM mysql.user 在主库有结果、从库返回空；SHOW GRANTS FOR 'u'@'h' 报错 ERROR 1141 (42000)；应用连从库直接被拒，提示 Access denied for user。
检查是否跳过 mysql 库：
- 查
SHOW SLAVE STATUS\G中的Replicate_Ignore_DB字段是否含mysql - 或执行
SELECT * FROM performance_schema.replication_applier_configuration
直接 INSERT INTO mysql.user 是危险操作
绕过 GRANT、手动往 mysql.user 表里插数据，不仅不会触发权限重载，还极大概率导致 binlog 记录损坏：ROW 格式下可能生成非法事件，从库回放失败；SBR 模式下也可能因语句非确定性而引发主从不一致。
GRANT 是原子性 DDL，在支持版本中能正确生成可复制的 binlog 事件，例如：
CREATE USER 'reporter'@'%' IDENTIFIED BY 'pwd'; GRANT SELECT ON db.* TO 'reporter'@'%';
执行完无需手动 FLUSH PRIVILEGES（GRANT 自动重载），但从库若延迟大，可酌情在从库执行一次确保内存权限即时生效。
GTID 模式下权限同步更敏感
如果启用了 GTID，GRANT 语句必须作为独立事务提交，否则可能和其它 DML 混在一个 GTID 事务里，导致从库解析失败或跳过整个事务。尤其要注意避免在同一个事务里混合 DDL 和 DML。
验证方式：
- 主库执行
SELECT @@gtid_mode;确认是否为ON - 检查出错事务的 GTID 是否完整（看
SHOW SLAVE STATUS\G中的Executed_Gtid_Set和Last_SQL_Error提示的 GTID） - 禁止用
SET GLOBAL sql_slave_skip_counter = 1跳过 GTID 复制错误，必须用SET GTID_NEXT方式精准跳过
权限表结构差异也会让 GRANT 失效
主从库 mysql.user 表字段数或类型不一致（比如主库是 8.0、从库是 5.7），即使 GRANT 成功写入 binlog，从库回放时也可能报 Column count doesn't match value count 或字段赋值越界。
排查方法：
- 对比主从库执行
SHOW CREATE TABLE mysql.user\G - 确认
slave_type_conversions未启用（默认为空，不自动兼容） - 避免跨大版本搭建主从；若已发生，优先升级从库版本，而非降级主库
真正要命的不是授权语句写错了，而是它根本没走通复制链路——要么被过滤，要么格式不兼容，要么事务包得太紧。这些细节在主库看着一切正常，一到从库就断得无声无息。
