MySQL表复制：一条捷径与一条稳妥之路
开门见山，先说结论：想在MySQL里快速复制一张表，你面前有两条路。一条是看似一步到位的“捷径”——CREATE TABLE ... SELECT；另一条则是需要两步走的“稳妥之路”——先用CREATE TABLE ... LIKE复制结构，再用INSERT INTO ... SELECT填充数据。选哪条，完全取决于你对“完整性”的要求有多高。
“捷径”的代价：为什么CREATE TABLE ... SELECT容易翻车
没错，CREATE TABLE new_t SELECT * FROM old_t这条语句写起来是真痛快，一条命令就把结构和数据都搞定了。但问题恰恰出在这个“痛快”上。它的底层逻辑是根据查询结果来“推导”新表的定义，而不是“复制”原表的完整定义。这就导致了一系列关键信息的丢失：
- 主键和自增属性没了：原表里那个
AUTO_INCREMENT的id字段，到了新表很可能就变成一个普通的INT。结果呢？下次插入数据时，系统会直接报错：Field 'id' doesn't ha ve a default value。 - 索引集体消失：无论是唯一索引还是普通索引，这条语句一概不管。原表上精心设计的
UNIQUE KEY idx_email (email)，在新表里荡然无存，数据查重功能瞬间失效。 - 字符集和约束可能“跑偏”：跨库操作时尤其明显，原表的
utf8mb4_unicode_ci排序规则，新表可能莫名其妙地变成了latin1_swedish_ci。更别提如果原表有生成列或检查约束，这条语句会直接报错罢工。
所以，这条捷径更像是一个“结构快照”，只复制了最基础的列名和数据类型，把那些保证数据完整性和性能的关键“零件”全给落下了。
结构复制的“保真”之王：CREATE TABLE ... LIKE的能力边界
如果说上一条是“快照”，那么CREATE TABLE new_t LIKE old_t就是“克隆”。它是MySQL原生提供的、保真度最高的结构复制方案。但即使是“克隆”，也有它的能力边界，必须心里有数：
- 完美复制的部分：所有列定义（包括
NOT NULL、DEFAULT值、AUTO_INCREMENT属性）、主键、各类索引（唯一、普通、全文）、表的字符集、排序规则，甚至连自增序列的起始值都能一并拷贝过来。 - 无法带走的部分：外键约束、触发器、表注释、分区定义，以及一些存储引擎特有的参数（比如
ROW_FORMAT），这些都不会被复制。 - 一个关键提醒：
LIKE语句不会检查目标表是否已存在。如果new_t这个名字的表已经在库里了，它会毫不客气地报错：ERROR 1050 (42S01): Table 'new_t' already exists。执行前，务必确认表名是全新的。
黄金组合：先LIKE再INSERT SELECT的实战要点
“先克隆结构，再灌入数据”，这是生产环境里最稳妥的全量复制路径。但每一步操作，都有细节需要卡准：
- 空间与事务是首要考量：
INSERT INTO ... SELECT是一个大事务操作。复制超大表时，务必确保目标库有足够的磁盘空间，并且innodb_log_file_size配置足够大，否则可能因日志写满而失败，甚至触发长事务告警。 - 外键依赖必须提前解决：如果原表通过外键引用了其他表，那么在执行
INSERT之前，必须先在目标库创建好那些被引用的表，否则会报错ERROR 1452 (23000): Cannot add or update a child row。 - 性能优化小技巧：执行前，可以临时调大会话的排序缓冲区：
SET SESSION sort_buffer_size = 268435456;。这对于加速索引重建（特别是SELECT语句带ORDER BY时）很有帮助。 - 灵活复制部分数据：如果只想复制符合条件的数据，把
WHERE条件加在SELECT子句里就行，例如：INSERT INTO new_t SELECT * FROM old_t WHERE status = 'active';。 - 字段映射要明确：当新旧表字段数或名称不完全一致时，强烈建议显式列出字段名，避免数据错位：
INSERT INTO new_t (id, name, created_at) SELECT id, user_name, add_time FROM old_t;。
何时需要升级工具：转向mysqldump的场景
当你的需求超出了单表、单实例的范围，比如需要跨MySQL实例复制，或者必须保留外键、触发器、表注释等LIKE语句无法覆盖的元数据时，就该请出更强大的工具——mysqldump了。
- 只导出结构（包含外键）：
mysqldump -d --skip-triggers db_name table_name > struct.sql - 导出结构+数据（确保一致性）：
mysqldump --single-transaction -t db_name table_name > data.sql - 一个容易踩的坑：
mysqldump生成的SQL文件里，表名是硬编码的。如果你想把表old_t复制为new_t，必须手动在SQL文件里把所有的CREATE TABLE `old_t`替换成CREATE TABLE `new_t`，漏掉一处就会建错表。 - 字符集一致性：导入前，务必确认目标数据库的字符集设置与源库一致。
mysqldump默认使用连接时的字符集输出数据，配置不当可能导致乱码。
最后，必须警惕的是锁的影响。无论是结构复制还是数据灌入，都不是在真空中进行的。CREATE TABLE ... LIKE会对原表加一个MDL_SHARED_READ锁，这会阻塞其他DDL操作。而INSERT INTO ... SELECT在可重复读隔离级别下，会开启一个事务并持有涉及到的行锁。如果原表正在被业务高频更新，这两步操作都可能成为线上服务抖动的源头。因此，评估复制方案时，不能只看语法是否正确，更要考虑它在你的实际生产环境里，可能会“卡”在哪个环节。
