数据库复制表结构全攻略：主流数据库语法与避坑指南-北京尧图网络

1. 复制表结构之前先搞清楚你到底要复制什么做数据库开发这些年复制表结构这个需求我接过无数次但真正让我印象深刻的是第一次因为表结构没复制完整而翻车的经历。当时业务流程很简单测试环境要快速克隆一张生产环境的订单表我二话不说用了CREATE TABLE AS SELECT还特意加了WHERE 10自认为天衣无缝。结果跑数据校验的时候业务同事直接找上门来主键没了、自增没了、默认值没了连字段注释都丢得一干二净。更要命的是这张表后面还挂了好几个外键关联下游脚本全炸了。那次之后我才真正意识到复制表结构这事远不是复制几个字段名和类型那么简单。一张表的结构至少包含五层东西字段定义字段名、数据类型、长度、精度、是否允许为空。字段级属性默认值、自增/序列、生成列、注释、字符集/排序规则。表级约束主键、唯一键、外键、检查约束。表级附属物索引、分区、表注释、存储参数如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 10;WHERE 10是为了让它只出结构、不出数据。但这样建出来的表字段类型和查询结果集一致主键、索引、自增、默认值全部丢失。有些版本连字段注释都保不住。如果是临时分析、报表中间表用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 ColumnINCLUDING GENERATED会把生成表达式复制过去但如果你用的是CREATE TABLE AS方式生成的列会被当成普通列而且因为表达式太长很容易在复制过程中被截断或丢失。所以涉及生成列的表建议一律走LIKE路线。外键PG的LIKE明确不支持外键。要复制外键体系最实用的做法是用pg_dumppg_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 NULLPG里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 INTO4.1 SQL Server的SELECT INTO只要结构就选个寂寞SQL Server里有一招非常经典的写法SELECT * INTO 新表 FROM 旧表 WHERE 10。注意这是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_METADATAOracle复制表结构的标准姿势是CTAS加WHERE 10CREATE TABLE orders_copy AS SELECT * FROM orders WHERE 10;但结果和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 SELECTCTAS非常轻量但你也要接受它的轻量带来的代价CREATE TABLE orders_copy AS SELECT * FROM orders WHERE 0;这样建出来的新表没有主键、没有自增、没有默认值字段类型也可能被隐式转换。更坑的是SQLite的字段类型本来就是弱类型CTAS出来的字段类型常常变得面目全非比如INTEGER PRIMARY KEY可能变成普通的INT。5.2 通过sqlite_master实现真复制SQLite里真正的复制表结构我一般用sqlite_master来抓原表的建表SQLSELECT 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 UNSIGNEDPG没有无符号整数概念SMALLINT范围约±32000能覆盖MySQLTINYINT UNSIGNED0~255的实际存储需求但如果你原表用的是INT UNSIGNED就得升级到BIGINT。这也是为什么建表时不要为了省空间乱设类型否则迁移时每一个类型都要费心去换算。AUTO_INCREMENTPG里有两种映射方式PG10以上用GENERATED ALWAYS AS IDENTITY最省心老版本用SERIAL等价但后续管理麻烦。DATETIME对应PG的TIMESTAMP需要注意是否带时区。MySQL的DATETIME不带时区映射成TIMESTAMP WITHOUT TIME ZONE才语义一致。COMMENTMySQL写在列定义里PG要单独执行COMMENT ON。类型映射这件事最怕的就是看着像就用了。比如MySQL的VARCHAR(255)在不同字符集下能存的实际内容字节数差很多到了PG里如果库的默认编码是UTF8VARCHAR(255)按字符算反而比MySQL更能装多字节内容。安全迁移前建议先跑一次数据抽查别完全相信自动转换工具。6.2 自增列到底怎么翻译自增列是我每次讲跨库复制都绕不开的痛点。原因很简单它绑定着新插入数据的主键不冲突这一刚需。四家数据库的做法对比如下数据库自增实现复制结构时是否带自增复制后推荐做法MySQLAUTO_INCREMENTLIKE 会带直接可用PostgreSQLIDENTITY / SERIAL SEQUENCEIDENTITY 可带SERIAL 序列不复制重建序列并 setval 到当前最大值SQL ServerIDENTITY 属性SELECT INTO 丢失建表后手动加 IDENTITY_INSERT 或重建OracleIDENTITY 列或序列触发器CTAS 丢失重建序列或IDENTITY属性跨库迁移自增列最需要记的一条经验是新表建好后别忘了把自增序列的起点设置成原表当前最大值加1。否则从1开始自增一旦插入了ID1的数据后续会和历史数据撞车。在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 TABLEMySQL或查pg_constraintPG看主键、唯一键、检查约束是否齐全。缺失的就手动补例如-- 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 ONSELECT 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里如果你在库级别、表级别、列级别分别指定了不同的CHARSETLIKE复制的是表级字符集但某些列可能单独指定过不同排序规则。跨库同步后中文排序顺序可能与原库不一致尤其是做ORDER BY中文列的时候结果能把你整懵。建议复制完检查每一列的COLLATION。第三个坑临时分析表误用了生产库的约束。有时候需求只是给我拉一份和线上结构一样的临时表跑几条SQL结果你直接CREATE TABLE ... LIKE把外键也复制过来了。后续删除数据时各种外键冲突查了半天才发现源头是这张临时表。后来我做分析用临时表都主动降级只保留字段和必要的索引外键、触发器、生成列一律不要。这样才能保证复制出来的表是真的拿来干活的而不是给自己添堵。最后再分享一个我自己的习惯任何复制表结构的操作执行完第一步永远是SELECT COUNT(*)对比原表和新表的数据量第二步是查看information_schema或系统目录里的约束、索引数量。结构是否完整用数据说话不要用眼睛看执行成功与否来判断。把握住复制后必检查这条铁律再冷门的数据库类型你也能游刃有余。

数据库复制表结构全攻略：主流数据库语法与避坑指南

相关推荐

MySQL MVCC机制详解：版本链、ReadView与RC/RR差异

文本到可视化多模态生成基准与评估框架：用TaoToken统一Key跑通评测流水线

平台化十年：从烟囱式架构到业务中台的演进与落地实践

更多资讯

Orange AI 管理平台 MCP 服务管理：用 TaoToken 统一 Key 打通多工具调用链

6个免费好用可替代Notepad++的记事本软件下载：从Vim到TaoToken配置的文本编辑器选型指南

Caused by: java.lang.ClassNotFoundException: org.apache.ibatis.cursor.Cursor解决方法：SSM 项目 mybatis-spri

Cursor Rules深度实战2026：用TaoToken统一Key把AI编程助手调教成你的专属架构师

openClaw接入飞书机器人：TaoToken统一Key打通消息链路

舰船识别大数据系统：AIS+卫星+雷达多源融合实战

今日更新

插件加载失败深度解析：从did not activate到生命周期排查指南

SpringBoot+Vue+MyBatis企业级房屋租赁管理系统源码解析

企业核心数据灾备自动化：用 OpenClaw 备份到本地 + 云端 + 离线存储的 TaoToken 统一通道实践

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？