mysql 8.0 clone插件不复制用户权限逻辑，仅物理拷贝mysql.user等系统表文件；克隆后因authentication_string、plugin字段不兼容或新增权限字段缺失，导致登录失败或授权异常，须手动重置认证方式、补全角色并校验上下文。
MySQL 8.0 的 CLONE 插件本身不处理用户权限克隆——它只复制数据文件和系统表的二进制内容。所谓“克隆插件执行时的用户权限报错”，实际是克隆后新实例启动时，因权限元数据与当前认证插件/密码策略不兼容导致的登录失败或授权异常，不是插件执行阶段报错。
CLONE 后 mysql.user 表数据无法直接生效的原因
克隆操作（如 CLONE LOCAL DATA DIRECTORY）会把源实例的 mysql.user、mysql.role_edges 等系统表以 ibd 文件形式原样拷贝。但这些数据在新实例中加载时会触发校验：
-
caching_sha2_password用户记录若遇到旧客户端或未配置对应插件，连接时直接报Access denied，不是权限缺失，而是认证链断裂 - MySQL 8.0 新增的密码策略字段（如
password_reuse_history、password_require_current）在源实例未启用时值为NULL，克隆后可能被强制校验，导致ALTER USER或登录失败 - 角色绑定信息（
mysql.role_edges）虽被克隆，但若目标实例未启用角色功能（activate_all_roles_on_login=OFF），角色不会自动激活
克隆后必须手动修复的权限相关操作
不能依赖克隆结果“开箱即用”，以下三步缺一不可：
- 启动新实例后，先用
CURRENT_USER()确认能否以 root 或管理账号登录（建议用--skip-grant-tables启动临时绕过，仅限安全环境） - 对所有需要保留的用户，显式重置认证方式：
ALTER USER 'u1'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';（避免 caching_sha2_password 兼容问题） - 检查并补全角色授权：
SELECT FROM_HOST, FROM_USER, TO_HOST, TO_USER FROM mysql.role_edges WHERE FROM_USER = 'target_user';，再执行GRANT role_name TO 'target_user'@'%'; SET DEFAULT ROLE role_name TO 'target_user'@'%';
为什么不能直接 INSERT INTO mysql.user 或 mysqldump mysql 库
这是最常踩的坑：手动向 mysql.user 插入记录会立即报错 ERROR 1136 (21S01): Column count doesn't match value count，因为 MySQL 8.0 的该表已有至少 5 个新增字段（如 account_locked、password_reuse_time），而旧版 dump 或手写 SQL 没包含它们。
同理，mysqldump mysql 导出的 SQL 在新实例执行会失败——系统库结构受版本强约束，不是纯数据迁移场景。
真正关键的不是“怎么克隆”，而是克隆后是否意识到：权限不是数据，是运行时上下文逻辑。哪怕克隆成功，mysql.user 里多一个 NULL 字段、少一个角色映射、插件不匹配，都会让整个权限体系失效。
