create table ... like能保主键和索引，因直接读取原表元数据（如information_schema），精准复制列定义、主键、各类索引、auto_increment、字符集等；但不复制外键、触发器、表注释、分区及row_format等。
CREATE TABLE ... LIKE 为什么能保主键和索引
CREATE TABLE new_t LIKE old_t 直接读取原表的元数据（INFORMATION_SCHEMA 中的列定义、索引定义、约束定义），不是靠“猜”结果集结构。它能复制：NOT NULL、AUTO_INCREMENT、主键、唯一索引、普通索引、全文索引、字符集、排序规则、自增起始值。
但注意：它不复制外键、触发器、表注释、分区定义、ROW_FORMAT 等部分存储引擎参数。执行前必须确认目标库不存在同名表，否则报错 ERROR 1050 (42S01): Table 'new_t' already exists。
常见误操作：
- 在有外键依赖的库中直接用
LIKE，后续INSERT会因被引用表缺失而报ERROR 1452 (23000) - 原表带
COMMENT，新表没注释，需手动补：ALTER TABLE new_t COMMENT = 'xxx'
INSERT INTO ... SELECT * 为什么会失败或丢数据
这步看似简单，但字段顺序、类型、NULL 性必须严格对齐。如果两表字段数不等、顺序不一致、或某列为 NOT NULL 但源数据含 NULL，语句直接报错或静默截断。
实操建议：
- 显式列出字段：
INSERT INTO new_t (id, name, email) SELECT id, name, email FROM old_t，避免隐式匹配风险 - 大表导入前调大会话参数：
SET SESSION sort_buffer_size = 268435456，加速索引重建 - 若原表有生成列（
GENERATED COLUMN）或CHECK约束，SELECT *会失败，必须排除这些列或改用其他方式
为什么 CREATE TABLE ... SELECT * 不能用于生产克隆
CREATE TABLE new_t SELECT * FROM old_t 是按查询结果反推建表，本质是“快照式建表”，不是结构克隆。它只保留列名、基础类型、部分默认值，其余全丢：
- 主键变成普通字段 → 插入时爆
Field 'id' doesn't have a default value -
UNIQUE KEY idx_email (email)消失 → 查重完全失效 - 跨库复制时字符集可能降级为
latin1_swedish_ci→ 中文乱码、排序异常 - 遇到
GENERATED COLUMN或CHECK约束直接报错退出
它只适合临时分析表、ETL 中间表、只读快照等无约束依赖的场景。
组合操作的实际卡点在哪
最稳妥路径是 CREATE TABLE ... LIKE + INSERT INTO ... SELECT，但两步之间有隐藏耦合：
- 第二步必须确保目标表为空且结构已就位，否则重复执行会报主键冲突或重复插入
- 若原表正在写入，
INSERT SELECT是单事务，大表可能触发长事务告警或撑爆innodb_log_file_size - 没有自动处理外键引用关系，若新表要参与外键约束，得先建好被引用表，并在
INSERT后手动加ALTER TABLE ... ADD FOREIGN KEY
真正容易被忽略的是：字段顺序和 NOT NULL 属性必须完全一致，哪怕只是多一个空格或默认值表达式不同，都可能导致 INSERT 失败或数据截断——这不是语法错误，而是运行时数据校验失败。
