INSERT INTO ... SELECT 是最直接可控的跨表数据复制方式，适用于目标表已存在且结构兼容的场景；它只搬运数据不建表，需确保字段数量、顺序、类型基本一致，并显式列出字段名以避免隐式匹配错误。
用 INSERT INTO ... SELECT 实现跨表数据复制
这是最直接、最可控的跨表数据克隆方式，适用于目标表已存在且结构兼容的场景。它不创建新表，只搬运数据，因此必须确保字段数量、顺序、类型基本一致（MySQL 会尝试隐式转换，但 ENUM、JSON、BLOB 等类型容易出错）。
常见错误现象：ERROR 1265 (01000): Data truncated for column 'xxx' 或插入后数值异常，多因源表某列是 TINYINT(1) 存布尔值，而目标表是 BOOLEAN 或 ENUM，导致语义丢失。
- 务必显式列出字段名，避免靠顺序匹配：用
INSERT INTO t2 (a, b, c) SELECT x, y, z FROM t1，而不是INSERT INTO t2 SELECT * FROM t1 - 若字段名不一致或需计算，直接在
SELECT中重命名或转换：例如SELECT id AS user_id, CONCAT(first_name, ' ', last_name) AS full_name FROM users - 大表复制时加
LIMIT分批执行，并在事务外操作（SET autocommit = 0），否则单次事务过大可能撑爆 undo log - 目标表有主键/唯一索引时，重复数据会报
ERROR 1062；可加ON DUPLICATE KEY UPDATE处理冲突，或先TRUNCATE再插（注意外键约束是否启用）
用 CREATE TABLE ... LIKE + INSERT INTO ... SELECT 完整克隆
这是生产环境推荐的「结构+数据」双保方式。第一步 LIKE 复制原表全部元数据（主键、索引、AUTO_INCREMENT 值、COMMENT、分区定义等），第二步再灌数据——两步分离，便于排查和重试。
容易踩的坑：LIKE 不复制外键约束（即使原表有 FOREIGN KEY），也不复制触发器、存储过程依赖项。MySQL 9.6.0 虽将外键逻辑上移到 SQL 层，但 LIKE 仍不带外键定义，必须手动补 ALTER TABLE ... ADD FOREIGN KEY。
- 跨库克隆时，
LIKE支持库前缀：CREATE TABLE db2.new_t LIKE db1.old_t，但要求两库在同一实例 -
INSERT INTO ... SELECT默认使用REPEATABLE READ隔离级别，对源表加共享锁（S lock），会阻塞UPDATE/DELETE；如需降低影响，可搭配SET SESSION transaction_isolation = 'READ-COMMITTED'（仅限非关键业务时段） - 目标表引擎必须与源表一致；用
SHOW CREATE TABLE old_t查看ENGINE=InnoDB，建表时显式指定，避免默认引擎差异
用 mysqldump 跨实例克隆表（含结构+数据）
当源表和目标表不在同一 MySQL 实例时，mysqldump 是最稳妥的选择。它导出的是完整可重放的 SQL，包含 CREATE TABLE 和逐条（或批量）INSERT，天然规避结构不一致风险。
性能影响明显：导出过程对源库是只读压力（--single-transaction 下几乎无锁），但导入时目标库写入压力集中；1000 万行以上建议加 --skip-extended-insert 减少单条 INSERT 长度，提升解析速度。
- 关键参数组合：
mysqldump -u u -p --single-transaction --quick --no-autocommit db tbl | mysql -u u -p target_db -
--quick强制逐行读取，防止大结果集占满内存；--single-transaction对 InnoDB 表保证一致性快照 - 若只要结构不要数据，加
--no-data；只要数据不要建表语句，加--no-create-info - 跨版本迁移需注意：MySQL 9.6.0 的
container_aware启动选项不影响 dump 文件兼容性，但导入前应确认目标实例支持源表所用语法（如生成列、JSON 函数）
为什么别用 CREATE TABLE ... AS SELECT 做跨表克隆
它看起来最省事，但本质是“按结果集反推建表”，不是克隆。你得到的是一张裸表：没主键、没索引、没 AUTO_INCREMENT、没注释、没外键、没触发器、没分区——连 ENUM('a','b') 都可能变成 VARCHAR(1)。
真实后果：刚克隆完查 SELECT COUNT(*) 很快，但加个 WHERE status = 'active' 就全表扫描；上线后因缺失主键，应用批量插入报 ERROR 1062；更糟的是，如果原表靠 ON DELETE CASCADE 维护数据一致性，新表完全失去该能力，后续数据会悄然腐化。
- 唯一合理用途：临时分析快照，比如
CREATE TABLE logs_20260902 AS SELECT * FROM logs WHERE dt = '2026-09-02'，用完即删 - 字段别名必须显式写，否则新表字段名为
COUNT(*)这类非法标识符，后续无法引用 - 目标表已存在时直接报
ERROR 1050，IF NOT EXISTS不支持，只能先DROP TABLE IF EXISTS——这在生产库极危险
跨表克隆真正的复杂点不在语法，而在约束传播和一致性边界：外键要按依赖顺序建，自增起始值要对齐，时间戳字段的 DEFAULT CURRENT_TIMESTAMP 在新表中是否还生效——这些细节不会报错，但会在几小时或几天后暴露为数据异常。动手前，先 SHOW CREATE TABLE 对比源目标，比写十行 SQL 更重要。
