1. 复制表结构之前，先搞清楚你到底要复制什么

做数据库开发这些年，"复制表结构"这个需求我接过无数次，但真正让我印象深刻的，是第一次因为"表结构没复制完整"而翻车的经历。

当时业务流程很简单：测试环境要快速克隆一张生产环境的订单表，我二话不说用了CREATE TABLE AS SELECT，还特意加了WHERE 1=0，自认为天衣无缝。结果跑数据校验的时候，业务同事直接找上门来：主键没了、自增没了、默认值没了，连字段注释都丢得一干二净。更要命的是，这张表后面还挂了好几个外键关联，下游脚本全炸了。

那次之后我才真正意识到：复制表结构这事，远不是"复制几个字段名和类型"那么简单。一张表的"结构"至少包含五层东西：

• 字段定义：字段名、数据类型、长度、精度、是否允许为空。
• 字段级属性：默认值、自增/序列、生成列、注释、字符集/排序规则。
• 表级约束：主键、唯一键、外键、检查约束。
• 表级附属物：索引、分区、表注释、存储参数（如MySQL的ENGINE、PostgreSQL的TABLESPACE）。
• 权限与依赖：授权信息、触发器、物化视图依赖等（这部分绝大多数"复制结构"工具并不会帮你带过去）。

换句话说，你问"怎么复制表结构"，本质上是在问："我到底需要多完整的结构？"——是只要字段能对上，还是约束、索引、注释都得一模一样？不同的答案，对应着完全不同的写法。

所以在动手之前，我习惯先列一张"复制清单"，跟业务方对清楚三件事：

• 只要空表结构，还是一并复制数据？
• 约束和索引要不要跟着走？
• 是同一个数据库内复制，还是要跨数据库、甚至跨数据库类型？

这三个问题确定之后，下层的语法选型就很简单了。下面我按主流数据库逐个拆解各自的做法和坑，最后再聊跨库复制时最容易被忽略的内容。

2. MySQL：一条CREATE TABLE LIKE走天下，但别忽略它的边界

2.1 基础语法与实测表现

MySQL里复制表结构最正统的写法是CREATE TABLE ... LIKE，这也是官方文档明确推荐的方式。它的语义是"按原表的定义创建一个新表，包含完整的列、索引和一些表属性"。

CREATE TABLE orders_copy LIKE orders;

这条语句执行完之后，新版表会包含原表的所有字段定义、主键、唯一键、索引、默认值、自增属性（AUTO_INCREMENT当前值也会被重置为初始值）、以及ENGINE、CHARSET、COMMENT等表级属性。实测下来，这是MySQL所有复制方式里最接近"像素级复制"的写法。

但这里有个容易忽略的细节：LIKE只复制结构，不复制外键。对，你没看错。虽然文档里没把话说绝，但实测在不同版本下，外键约束经常不会跟着LIKE走，尤其是当原表和其他表存在关联关系时。你需要手动补外键，或者用下面的方式处理。

相比之下，CREATE TABLE AS SELECT（简称CTAS）就是另一种路子了。它本质上是"把查询结果集变成一张表"，所以结构信息完全由查询结果决定：

CREATE TABLE orders_copy AS SELECT * FROM orders WHERE 1=0;

WHERE 1=0是为了让它只出结构、不出数据。但这样建出来的表，字段类型和查询结果集一致，主键、索引、自增、默认值全部丢失。有些版本连字段注释都保不住。如果是临时分析、报表中间表，用CTAS完全没问题；但如果你计划拿它当业务表的正式副本，那就是给自己埋雷。

2.2 不能靠LIKE硬扛的场景

LIKE也不是万能的。我实际使用中遇到过几个它搞不定的场景：

跨库复制。CREATE TABLE db2.orders_copy LIKE db1.orders;这种写法，在MySQL里是不允许的。你必须在目标库里先建好表，或者用导出导入的方式。跨库复制表结构，我的常规操作是：

mysqldump -u root -p --no-data --single-transaction db1 orders > /tmp/orders.sql mysql -u root -p db2 < /tmp/orders.sql

--no-data表示只要结构不要数据，--single-transaction保证在InnoDB下导出时的一致性。这样连外键、触发器、视图依赖关系都能完整带过去，也是我实际工作中最稳妥的跨库方案。

分区表。LIKE能不能带分区？在MySQL 5.7及之前，CREATE TABLE ... LIKE不会复制分区定义；从MySQL 8.0开始，实测LIKE可以复制分区。但如果你用的还是5.x的老库，建完表记得检查SHOW CREATE TABLE输出里有没有PARTITION BY这一段，没有的话就得手动补分区。

临时表。CREATE TEMPORARY TABLE ... LIKE是可用的，但临时表本身就不太支持外键和分区，所以这算半个边缘场景，知道有这么回事即可。

2.3 需要连数据一起搬？CTAS的正确姿势

如果需求是"复制表结构，同时把数据也搬过去"，MySQL下我一般分两种情况处理：

• 数据量小（百万行以内）：直接CREATE TABLE orders_copy AS SELECT * FROM orders;然后手动补主键、索引和默认值。虽然CTAS不带约束，但它快、直接，适合一次性分析。
• 数据量中等以上：先CREATE TABLE orders_copy LIKE orders;再INSERT INTO orders_copy SELECT * FROM orders;。这样既保留了完整结构，数据迁移逻辑也清澈，中间任一步失败都好回滚。
• 超大表在线搬迁：用CREATE TABLE ... LIKE建好骨架之后，配合pt-archiver或gh-ost这类工具按主键分批搬数据，避免一次性大事务把主库锁死。这是DBA的活儿，但开发同学了解这个思路对排查慢查询也很有帮助。

3. PostgreSQL：老大哥的Like语法比MySQL更"完整"，但版本差异巨大

3.1 INCLUDING ALL 到底包含了什么

PostgreSQL 也提供CREATE TABLE ... LIKE，但它的语义比MySQL丰富得多。关键就在这个子句：INCLUDING。

CREATE TABLE orders_copy (LIKE orders INCLUDING ALL);

INCLUDING ALL是以下所有选项的合集：

• INCLUDING DEFAULTS：默认值
• INCLUDING CONSTRAINTS：检查约束和非空约束（注意：不包含外键，外键需要单列）
• INCLUDING INDEXES：索引、主键、唯一约束对应的索引
• INCLUDING STORAGE：存储参数
• INCLUDING COMMENTS：字段和表的注释
• INCLUDING GENERATED：生成列
• INCLUDING IDENTITY：标识列（自增）
• INCLUDING STATISTICS：统计信息
• INCLUDING REPLICA IDENTITY

实测下来，INCLUDING ALL能把主键、唯一约束、默认值、注释、索引全部带过去，这比MySQL的LIKE还省心。但有个坑：它不复制外键、不复制序列（SEQUENCE）、不复制触发器。尤其是序列这个问题，我踩过不止一次。

3.2 序列、生成的列、外键的版本坑

序列是PG里自增的底层机制，在PG10之前用SERIAL伪类型，PG10之后推荐IDENTITY列。当你CREATE TABLE new_table (LIKE old_table INCLUDING ALL)时：

• IDENTITY列在PG10+ 可以被INCLUDING IDENTITY带过去，新表会有自己的一套序列。
• 老的SERIAL列本质上是一个DEFAULT nextval('xxx_seq')，INCLUDING DEFAULTS会把默认值表达式也复制过去，但序列对象本身不会复制。于是新表插入数据时会报错：currval of sequence "xxx_seq" is yet to be defined in this session或者提示序列不存在。

解决办法是建表后重新绑定一个新序列：

CREATE SEQUENCE orders_copy_id_seq START 1; ALTER TABLE orders_copy ALTER COLUMN id SET DEFAULT nextval('orders_copy_id_seq');

生成的列（Generated Column）：INCLUDING GENERATED会把生成表达式复制过去，但如果你用的是CREATE TABLE AS方式，生成的列会被当成普通列，而且因为表达式太长，很容易在复制过程中被截断或丢失。所以涉及生成列的表，建议一律走LIKE路线。

外键：PG的LIKE明确不支持外键。要复制外键体系，最实用的做法是用pg_dump：

pg_dump --schema-only -t orders target_db > orders_schema.sql

--schema-only只导出结构，包括外键、序列、触发器、注释、权限全都在。然后在目标库执行这个SQL文件，比手写LIKE稳妥得多，尤其是一张表关联了一堆外键的时候。

3.3 PG的CTAS与传统路径

PG里的CREATE TABLE AS用法和MySQL的CTAS类似，同样只保留字段类型和NOT NULL（PG里CTAS会保留非空约束），其他约束和索引全部丢失：

CREATE TABLE orders_copy AS SELECT * FROM orders WHERE false;

补充一个冷知识：PG里还有一个SELECT INTO语法，效果等同于CREATE TABLE AS，在PL/pgSQL函数里仍然常用：

SELECT * INTO orders_copy FROM orders WHERE false;

但在普通SQL交互环境下，PG官方更推荐CREATE TABLE AS，因为SELECT INTO的行为在更多场景下不够直观。如果是函数内部创建临时表，我倒是常用SELECT INTO，因为它写法简短，且临时表本来就不太在意约束。

4. SQL Server与Oracle：不靠"Like"靠"脚本"，顺便聊聊SELECT INTO

4.1 SQL Server的SELECT INTO：只要结构就选个寂寞

SQL Server里有一招非常经典的写法：SELECT * INTO 新表 FROM 旧表 WHERE 1=0。注意这是SQL Server系特有的语法，MySQL和PG都不支持这么写。

但如果你指望它像MySQL的LIKE一样把主键、索引全带过去，那就要失望了。SELECT INTO在SQL Server里只复制列结构（包括字段名、类型、NULL/NOT NULL），主键、标识列（IDENTITY属性）、默认值、索引、约束一概不带。

打个比方：它像是给表"拍了张裸照"，五官身材在，但衣服首饰全没了。所以我通常只在快速生成一张中间分析表时用它，比如：

SELECT * INTO #tmp_orders FROM dbo.orders WHERE 1 = 0;

需要带完整约束的话，SQL Server里的正路是用SSMS生成脚本。右键点击原表 → Script Table as → CREATE To → New Query Editor Window，拿到完整的CREATE TABLE语句，里面包含了列、约束、索引、默认值的一切定义。然后手动改表名再执行。这种方式虽然多两步操作，但最不会丢东西。

4.2 用SSMS生成建表脚本的正规操作

SSMS生成脚本有一些细节值得注意：

• Script Table as 默认不会带索引，需要在"工具→选项→SQL Server对象资源管理器→脚本/表的脚本选项"里把"Indexes"打开。
• 外键依赖的脚本默认也会省略，要么用"Script related objects"补全，要么在生成向导里勾选"包含相关对象"。
• 如果要复制到另一台服务器，记得在"高级"里把"Database"切换为目标库，否则生成的脚本里可能带错误的三部分名称。

如果不想打开图形界面，直接写SQL也一样：先从sys.columns查询所有列定义，手工拼一个CREATE TABLE语句。网上有现成的存储过程可以干这事，但维护成本不低，我建议能用SSMS就用SSMS，实在需要自动化再用SMO或者dbatools的Copy-DbaDbTableData系列。

4.3 Oracle的CTAS与DBMS_METADATA

Oracle复制表结构的标准姿势是CTAS加WHERE 1=0：

CREATE TABLE orders_copy AS SELECT * FROM orders WHERE 1=0;

但结果和SQL Server的SELECT INTO一样，约束、索引、注释全丢。Oracle对这种场景有更正式的工具：DBMS_METADATA.GET_DDL。

SELECT DBMS_METADATA.GET_DDL('TABLE', 'ORDERS', 'APP_USER') FROM dual;

拿到完整的DDL文本后，替换表名再执行，就能得到一张包含所有约束、注释、存储参数的表。这个办法对索引也有效：

SELECT DBMS_METADATA.GET_DDL('INDEX', 'IDX_ORDERS_ID', 'APP_USER') FROM dual;

还有一个更省事的图形化路径：PL/SQL Developer或DBeaver里右键表名 → 生成DDL / 导出结构，效果等价于GET_DDL的封装。

另外提醒一下Oracle玩家：如果是分区表，CTAS还容易遇到分区属性丢失的问题。建议直接GET_DDL拿整段分区定义，别手工补，分区表达式写错一个字都够你排查半天的。

5. SQLite这类轻量库：复制结构=偷梁换柱

5.1 CREATE TABLE AS 的致命缺陷

SQLite的CREATE TABLE AS SELECT（CTAS）非常"轻量"，但你也要接受它的轻量带来的代价：

CREATE TABLE orders_copy AS SELECT * FROM orders WHERE 0;

这样建出来的新表没有主键、没有自增、没有默认值，字段类型也可能被隐式转换。更坑的是，SQLite的字段类型本来就是"弱类型"，CTAS出来的字段类型常常变得面目全非，比如INTEGER PRIMARY KEY可能变成普通的INT。

5.2 通过sqlite_master实现"真复制"

SQLite里"真正"的复制表结构，我一般用sqlite_master来抓原表的建表SQL：

SELECT sql FROM sqlite_master WHERE type = 'table' AND name = 'orders';

拿到的sql字段就是原表的完整CREATE TABLE语句，直接把表名替换成新表名再执行，结构和约束就全部保留了。注意SQLite的外键在默认情况下不会自动启用，连接时需要执行PRAGMA foreign_keys = ON，否则外键建了也不生效。

如果遇到带索引的表，还需要抓索引定义：

SELECT sql FROM sqlite_master WHERE type = 'index' AND tbl_name = 'orders';

然后逐一改成新表名执行。这套操作虽然手工感强，但胜在绝对可控，适合在脚本里批量处理。

6. 跨库复制表结构：类型映射才是重头戏

6.1 一张MySQL表迁移到PostgreSQL，你会遇到什么

跨数据库类型复制结构，是所有方案里最考验经验的部分。语法差异还在其次，类型系统的差异才是真正的门槛。

比如一张MySQL表：

CREATE TABLE orders ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, status TINYINT NOT NULL DEFAULT 0, amount DECIMAL(10,2), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, remark VARCHAR(255) COMMENT '备注' );

迁移到PostgreSQL，你得手动把它翻译成：

CREATE TABLE orders ( id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, status SMALLINT NOT NULL DEFAULT 0, amount NUMERIC(10,2), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, remark VARCHAR(255) ); COMMENT ON COLUMN orders.remark IS '备注';

这里面几乎每一行都有坑：

• TINYINT UNSIGNED：PG没有无符号整数概念，SMALLINT（范围约±32000）能覆盖MySQLTINYINT UNSIGNED（0~255）的实际存储需求，但如果你原表用的是INT UNSIGNED，就得升级到BIGINT。这也是为什么建表时不要为了省空间乱设类型，否则迁移时每一个类型都要费心去换算。
• AUTO_INCREMENT：PG里有两种映射方式，PG10以上用GENERATED ALWAYS AS IDENTITY最省心，老版本用SERIAL等价但后续管理麻烦。
• DATETIME：对应PG的TIMESTAMP，需要注意是否带时区。MySQL的DATETIME不带时区，映射成TIMESTAMP WITHOUT TIME ZONE才语义一致。
• COMMENT：MySQL写在列定义里，PG要单独执行COMMENT ON。

类型映射这件事，最怕的就是"看着像就用了"。比如MySQL的VARCHAR(255)在不同字符集下能存的实际内容字节数差很多，到了PG里如果库的默认编码是UTF8，VARCHAR(255)按字符算，反而比MySQL更能装多字节内容。安全迁移前，建议先跑一次数据抽查，别完全相信自动转换工具。

6.2 自增列到底怎么翻译

自增列是我每次讲跨库复制都绕不开的痛点。原因很简单：它绑定着"新插入数据的主键不冲突"这一刚需。

四家数据库的做法对比如下：

跨库迁移自增列，最需要记的一条经验是：新表建好后，别忘了把自增序列的起点设置成原表当前最大值加1。否则从1开始自增，一旦插入了ID=1的数据，后续会和历史数据撞车。

在PG里可以这样写：

SELECT setval('orders_copy_id_seq', (SELECT COALESCE(MAX(id), 1) FROM orders));

SQL Server里如果表已经建好且带IDENTITY，可以用DBCC CHECKIDENT('orders_copy', RESEED, 1000)把种子值重设到1000之类的数值上，前提是你先知道原表的当前最大ID。

7. 结构复制完之后，别忘了补索引、补注释、补权限

7.1 建索引和补约束的通用套路

无论你用哪种方式复制表结构，我都会建议在复制完成后跑一遍"三查三补"：

一查约束。执行SHOW CREATE TABLE（MySQL）或查pg_constraint（PG），看主键、唯一键、检查约束是否齐全。缺失的就手动补，例如：

-- MySQL ALTER TABLE orders_copy ADD PRIMARY KEY (id); ALTER TABLE orders_copy ADD UNIQUE KEY uk_order_no (order_no);

二查索引。索引是复制结构时最容易被静默丢弃的部分。MySQL的LIKE会带索引，但CTAS不会；PG的LIKE ... INCLUDING ALL会带索引，但CTAS不会；SQL Server和Oracle基本都要手动补。建议用SHOW INDEX FROM orders;或 PG的pg_indexes视图拉一遍全部索引定义，再在目标表上重建。

三查权限和注释。字段注释、表注释、授权语句，大多不在复制范围内。批量场景下，可以用查询拼SQL的方式提高效率，比如PG里这样生成COMMENT ON：

SELECT 'COMMENT ON COLUMN orders_copy.' || column_name || ' IS ' || quote_literal(col_description('orders'::regclass, ordinal_position)) || ';' FROM information_schema.columns WHERE table_name = 'orders';

MySQL同理可以用information_schema.COLUMNS的COLUMN_COMMENT字段拼ALTER TABLE ... MODIFY COLUMN。这类操作虽然细节，但做完之后整张表才真正"能用"，而不是"能看"。

7.2 我踩过的三个坑

这些年下来，我总结了自己在复制表结构时踩得最狠的三个坑，写出来给大家避雷。

第一个坑：序列被复制，但指针没跟上。这是PG迁移的高频事故。用SERIAL的老表被复制后，新表默认值指向了原表的序列。此时往新表插数据，要么提示序列不存在，要么把原表序列的指针推高了，导致两表自增互相干扰。解决办法就是前面说的：复制后马上给新表重建序列，不要偷懒。

第二个坑：字符集和排序规则不同步。MySQL里如果你在库级别、表级别、列级别分别指定了不同的CHARSET，LIKE复制的是表级字符集，但某些列可能单独指定过不同排序规则。跨库同步后，中文排序顺序可能与原库不一致，尤其是做ORDER BY中文列的时候，结果能把你整懵。建议复制完检查每一列的COLLATION。

第三个坑：临时分析表误用了生产库的约束。有时候需求只是"给我拉一份和线上结构一样的临时表，跑几条SQL"，结果你直接CREATE TABLE ... LIKE把外键也复制过来了。后续删除数据时各种外键冲突，查了半天才发现源头是这张临时表。后来我做分析用临时表，都主动降级：只保留字段和必要的索引，外键、触发器、生成列一律不要。这样才能保证"复制"出来的表是真的拿来干活的，而不是给自己添堵。

最后再分享一个我自己的习惯：任何复制表结构的操作，执行完第一步永远是SELECT COUNT(*)对比原表和新表的数据量，第二步是查看information_schema或系统目录里的约束、索引数量。结构是否完整，用数据说话，不要用眼睛看执行成功与否来判断。把握住"复制后必检查"这条铁律，再冷门的数据库类型，你也能游刃有余。