clone插件仅支持物理文件拷贝，不处理ddl或逻辑对象；本地克隆必须用clone local directory且目标路径不存在、不嵌套于原datadir；远程克隆需两端innodb_file_per_table=on、正确配置clone_valid_donor_list与bind_address，并手动删除克隆后auto.cnf以避免server_uuid冲突。
CLONE 插件不支持“DDL克隆”——它根本不管 SQL 层的 DDL 操作，也不复制触发器、存储过程、视图定义以外的逻辑对象。所谓“实例级克隆”，本质是物理文件拷贝，不是执行 CREATE DATABASE 或 ALTER TABLE。
你真正想做的，是用 CLONE 快速获得一个含完整数据、表结构、索引、约束、系统表的**物理副本**，而非靠 DDL 语句重建。下面直说怎么做、为什么、哪里容易翻车。
CLONE INSTANCE 执行前必须确认 donor 和 recipient 的 innodb_file_per_table=ON
这是最常被忽略的硬性前提：innodb_file_per_table=OFF 的实例无法被克隆，目标端若仍为 OFF，会直接报 Invalid tablespace file。
- MySQL 8.0 默认开启该参数，但升级自 5.7 或手动改过配置的实例可能仍为 OFF
- 检查方式：在 donor 和 recipient 上分别执行
SELECT @@innodb_file_per_table;，结果必须是1 - 如果为
0，不能临时 SET，必须修改 my.cnf 并重启 mysqld 后再克隆
本地克隆只能用 CLONE LOCAL DIRECTORY，别碰 CLONE INSTANCE
试图在本机对同一 mysqld 实例执行 CLONE INSTANCE FROM 'user'@'127.0.0.1':3306 会触发循环检测失败，报错 ERROR 3095 或卡死在 clone_type 阶段。
- 本地备份/测试副本，只用
CLONE LOCAL DIRECTORY = '/path/to/clone_dir'; - 目标路径必须不存在（MySQL 自动创建），且不能嵌套在原
datadir内，否则报Directory overlaps with data directory - 路径属主必须是 mysqld 进程用户（如
mysql）：chown -R mysql:mysql /backup/clone_20260701
远程克隆失败 90% 是 clone_valid_donor_list 或 bind_address 配错
clone_valid_donor_list 是 recipient 端的全局变量，不是 session 级；donor 的 bind_address 若为 127.0.0.1，recipient 就连不上——这两处配错，直接触发 ERROR 3864 (HY000): Clone Donor connection failed 或静默超时。
- recipient 上执行：
SET GLOBAL clone_valid_donor_list = '192.168.1.100:3306';（注意：不能带http://，不支持 IPv6） - donor 的 my.cnf 中
bind_address必须设为0.0.0.0或具体内网 IP，不能是127.0.0.1 - 云环境还要检查安全组、SELinux、iptables 是否双向放行 3306
克隆完成后 auto.cnf 不删，实例就起不来
克隆是物理拷贝，auto.cnf 里的 server-uuid 也一并复制。recipient 启动时发现 UUID 冲突，直接拒绝服务，日志里只有模糊的 Could not open required defaults file 或 Server is running in --secure-file-priv mode 类似误导信息。
- 克隆完成、mysqld 自动退出后，手动进入目标数据目录，删掉
auto.cnf：rm /var/lib/mysql/auto.cnf - 启动前务必确认：
SELECT @@server_uuid;返回值与 donor 不同，否则说明没删干净或被其他进程重建 - 别指望 MySQL 自动处理——这是唯一必须人工干预的元数据点
