MySQL CREATE TABLE LIKE 复制检查约束与索引定义

MySQL 的 CREATE TABLE ... LIKE 适合复制一张空表的结构：它会带走源表的列属性和索引，并在 MySQL 8.4 中保留生成列、表达式默认值与 CHECK 约束；但外键定义不会复制，部分目录相关表选项也不会复制。需要复制数据或重建完整关系时，不能只看表名相似就直接套用。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/create-table-like.html

本文按“变化是什么、为什么这样设计、旧迁移代码会受什么影响、如何选择语句、怎样做最小核对”的顺序，围绕《MySQL CREATE TABLE LIKE 复制检查约束与索引定义》给出一套可直接改造的 SQL。

先区分 LIKE 与 CREATE TABLE ... SELECT

两种语句都能得到一张新表，但目标不同。CREATE TABLE target LIKE source 创建的是空表，重点是复制源表的定义；CREATE TABLE target AS SELECT ... 重点是把查询结果写入新表，查询结果的列类型会参与推导，而且不会自动为结果列创建索引。

如果任务是做归档表、影子表、临时导入表的结构起点，先用 LIKE。如果任务是把筛选后的行落地成快照，才考虑 AS SELECT，并把需要的主键、唯一索引和普通索引显式补上。

-- LIKE 复制结构，不复制源表中的行
CREATE TABLE archive_orders LIKE orders;

-- SELECT 复制查询结果；索引需要根据用途另外设计
CREATE TABLE order_snapshot AS
SELECT id, customer_id, total_amount
FROM orders
WHERE created_at 

这一步的决策点只有一个：新表是为了“按照原结构继续接收数据”，还是为了“保存一次查询结果”。前者优先 LIKE，后者要把数据类型、空值属性和索引策略一起重新确认。

用 LIKE 复制列属性和索引

下面准备一张含有主键、唯一索引、普通索引和生成列的源表。示例里的注释只解释本次迁移需要关注的字段，不把 SQL 改写成无效的伪代码。

-- 源表包含列属性、主键、唯一索引、普通索引和生成列
CREATE TABLE orders (
    id BIGINT NOT NULL AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL,
    customer_id BIGINT NOT NULL,
    total_amount DECIMAL(12, 2) NOT NULL DEFAULT 0.00,
    tax_amount DECIMAL(12, 2) NOT NULL DEFAULT 0.00,
    gross_amount DECIMAL(12, 2)
        GENERATED ALWAYS AS (total_amount + tax_amount) STORED,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id),
    UNIQUE KEY uk_orders_order_no (order_no),
    KEY idx_orders_customer_created (customer_id, created_at),
    CONSTRAINT chk_orders_amount CHECK (total_amount >= 0 AND tax_amount >= 0)
) ENGINE = InnoDB;

-- 目标表为空，但从源表复制结构定义
CREATE TABLE archive_orders LIKE orders;

执行后，目标表会得到相同的列属性和索引定义，包括主键、唯一索引、普通索引、生成列和默认值。表名、表数据以及用于定位源表的业务含义不会自动替换：例如索引名仍可能与源表相同，因此同一数据库内若存在命名约束，迁移脚本要按实际命名规则处理。

理解 CHECK、默认值与外键边界

LIKE 的“复制结构”不是把 SHOW CREATE TABLE 输出逐字复制。MySQL 8.4 文档明确了几个会影响迁移设计的边界：

其中最容易误判的是 CHECK 和外键。前者属于表定义约束，会进入目标表，但名称会重新生成；后者描述跨表关系，LIKE 不会把它带到目标表，因此不能把“新表创建成功”当成“完整关系已经迁移”。

-- 外键需要在目标表上显式补建；先确保被引用表已经存在
ALTER TABLE archive_orders
    ADD CONSTRAINT fk_archive_orders_customer
    FOREIGN KEY (customer_id) REFERENCES customers (id);

-- 约束与索引的名称、列和动作都应在目标环境中明确写出
SHOW CREATE TABLE archive_orders;

用最小 SQL 核对新表结构

本轮文章不把核对命令当成发布前验证，而是给实际迁移脚本使用的最小检查清单。SHOW CREATE TABLE 适合看完整定义，SHOW INDEX 适合快速看索引，INFORMATION_SCHEMA 适合生成可重复的自动化记录。

-- 查看目标表的完整建表定义，重点关注生成列、默认值和 CHECK
SHOW CREATE TABLE archive_orders;

-- 查看主键、唯一索引和普通索引的列顺序
SHOW INDEX FROM archive_orders;

-- 只列出目标表的约束，便于迁移脚本保存结构快照
SELECT CONSTRAINT_NAME, CONSTRAINT_TYPE
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'archive_orders'
ORDER BY CONSTRAINT_TYPE, CONSTRAINT_NAME;

核对时不要只比较列数量。至少要看四件事：生成列表达式是否仍然正确、默认值是否符合目标 SQL mode、复合索引列顺序是否保留、外键是否已经被显式重建。若只需要检查索引列顺序，可以把 SHOW INDEX 的 Key_name、Seq_in_index 和 Column_name 写入迁移日志。

把复制选择接入迁移策略

对于空的归档表或影子表，推荐把 LIKE 放在迁移脚本的第一步，再单独处理目标表特有的外键、分区、存储目录和权限。对于数据快照，使用 AS SELECT 后不要假设原表索引会出现；应根据快照查询和后续读取路径显式创建。

还要注意两个执行边界：LIKE 只适用于基础表，不适用于视图；执行者需要对源表具备读取定义所需的权限。若源表在不同 SQL mode 下创建，目标执行环境的模式也可能影响 CREATE TABLE LIKE 是否成功，所以发布迁移脚本时应把 SQL mode 作为环境前提记录下来。

常见问题

CREATE TABLE LIKE 会复制数据吗？

不会。它创建的是空目标表；需要复制数据时，要单独执行 INSERT ... SELECT 或选择 CREATE TABLE ... SELECT，并重新确认索引和约束。

为什么新表有 CHECK，但约束名变了？

MySQL 会保留 CHECK 约束语义，但在 LIKE 复制时为目标表生成约束名。因此后续脚本应按目标表重新读取约束，而不是硬编码源表的约束名。

外键为什么没有跟着复制？

外键是跨表关系，CREATE TABLE LIKE 不保留外键定义。目标表建立后，需要在被引用表已就绪的前提下，用 ALTER TABLE 显式添加。

什么时候应该用 CREATE TABLE ... SELECT？

当目标是保存一次查询结果、筛选后的数据集或汇总快照时使用。它不是结构克隆命令，主键、唯一索引和读取路径所需的普通索引都应另行设计。

总结

CREATE TABLE ... LIKE 的核心变化可以概括为：它复制的是空表结构，列属性和索引会跟随，生成列、表达式默认值与 CHECK 约束会保留，但 CHECK 名称会重新生成，外键和部分目录表选项不会跟随。迁移脚本先根据目标选择 LIKE 或 AS SELECT，再用 SHOW CREATE TABLE、SHOW INDEX 和约束查询做结构核对，最后显式补齐跨表关系，边界就清楚了。