GRANT在从库执行会直接导致复制中断，根本原因是MySQL强制禁止从库SQL线程修改mysql库：GTID模式下报ERROR 1786（违反GTID一致性），read_only启用时报ERROR 1290（被只读限制拦截）；权限变更必须且只能在主库执行CREATE USER+GRANT语句，并确保replicate_ignore_db不含mysql。
GRANT 本身不会导致主从复制中断——但在从库上执行 GRANT 会直接触发复制中断，且多数情况下不可逆恢复。根本原因不是语句语法错，而是 MySQL 对权限操作的底层约束：从库 SQL 线程默认禁止执行任何修改 mysql 库的 DDL/DML，尤其在 GTID 模式下会被强制拒绝。
GRANT 在从库执行报 ERROR 1786（GTID 不一致）
MySQL 8.0+ 启用 GTID 后，所有事务必须可被唯一标识并保证幂等回放。GRANT 是 DDL 操作，隐式产生事务，但它不满足 GTID 一致性要求：
- 权限变更涉及
mysql.user、mysql.db等系统表，这些表的更新被 MySQL 内核硬编码为“非事务安全”； - 即使你手动
BEGIN; GRANT ...; COMMIT;，MySQL 仍会抛出：ERROR 1786 (HY000): Statement violates GTID consistency； - 一旦 SQL 线程遇到该错误，
Slave_SQL_Running立即变为No，Last_SQL_Error明确提示该错误码。
这不是配置问题，是 MySQL 的强制限制。试图绕过（比如临时关 GTID）会破坏整个复制拓扑的可靠性，不建议。
GRANT 在从库执行报 ERROR 1290（read_only 拦截）
即使没开 GTID，很多生产从库会启用 read_only=1（或 super_read_only=1）防止误写。此时：
-
GRANT被视为写操作，需SUPER权限才能绕过read_only； - 但普通运维账号通常没有
SUPER，执行时直接报：ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement； - 若强行用 root 执行且跳过了
read_only检查，后续主库同步来同名GRANT时，从库会因权限记录冲突再次中断（比如密码哈希方式不同、插件不匹配）。
关键点：read_only 不是只拦 INSERT/UPDATE，它对所有修改系统元数据的操作一视同仁。
为什么有人坚持要在从库上 GRANT？
常见动机有三个，但都错了：
- “主库改完权限，从库还没同步过来，应用连不上” → 正确做法是等复制追平，或临时在从库
FLUSH PRIVILEGES;（仅刷新内存缓存，不改表）； - “想给从库单独开只读账号” → 权限应统一在主库创建，再靠复制下发；从库本地加账号等于埋雷，下次主库执行同名
DROP USER就炸； - “主库太忙，怕
GRANT影响性能” →GRANT是轻量 DDL，影响微乎其微；真正耗时的是后续FLUSH PRIVILEGES触发的权限重载，而复制本身已承担了这部分开销。
真正需要从库本地操作的，只有极少数场景：修复已中断的复制连接（如重建 repl 账号），且必须配合 STOP SLAVE + 手动建号 + START SLAVE，不能走常规复制流程。
从库权限不一致，到底该怎么修？
核心原则：权限变更必须源头可控、路径唯一、可审计。
- 主库执行标准语句：
CREATE USER 'u'@'%' IDENTIFIED BY 'p'; GRANT SELECT ON db.* TO 'u'@'%';； - 确保主库
log_bin=ON且未配置replicate_ignore_db=mysql； - 在从库检查：
SHOW SLAVE STATUS\G中Replicate_Ignore_DB不含mysql，Seconds_Behind_Master逐步归零； - 若已中断，先
STOP SLAVE，再在从库执行最小必要操作（如仅重建缺失的复制账号），完成后START SLAVE； - 禁止任何形式的
INSERT INTO mysql.user或UPDATE mysql.user—— 字段顺序、密码加密、插件兼容性全靠猜，失败率接近100%。
最容易被忽略的其实是配置继承：Ansible 模板、Dockerfile 或云数据库 RDS 的参数组，常把 replicate_ignore_db=mysql 默认写死。权限不同步问题，八成卡在这行配置上，而不是你写的那条 GRANT。
