表结构设计器 — 免费在线工具

表结构设计器是 CintaBox 芯塔盒在线工具箱提供的免费在线工具：把建表语句（DDL）粘进来，换一个数据库导出去 —— **MySQL / PostgreSQL / SQLite / SQL Server 四向互转**。

⭐⭐⭐ **换库会丢什么，工具一条条告诉你。**这是这个工具最要紧的一件事：MySQL 的**列注释**在 PostgreSQL 和 SQLite 的建表语句里根本写不了；**JSON** 类型 SQLite 没有；**自增**在 SQLite 只能用在整型主键上。⛔ 这些情况**都还是能生成出一份看起来正常的 DDL** —— 不告诉你的话，你是在真库上、甚至数据进去之后才发现少了东西。报告分三档：**丢失**（那个能力目标库没有）/ **语义变化**（存得进去但类型上分不出来了，比如 SQLite 把 varchar、日期、布尔写成同几个词，长度与格式校验都不强制）/ **写法不同**（等价，只是自增在 PostgreSQL 叫 SERIAL）。

⭐⭐ **「源数据库」要选对，工具会提醒你为什么。**同一个类型词在不同数据库里含义不一样 —— SQL Server 的 `FLOAT` 是**双精度**，而 MySQL 的 `FLOAT` 是**单精度**。选错了，双精度列会被读成单精度，**而生成的 DDL 看起来完全正常**。

⭐ **标识符默认全部加引号。**各数据库的保留字有几百个且随版本变，靠一张「保留字表」判断该不该加引号，漏一个就生成出跑不起来的 DDL —— 所以默认全加，**正确性不押在一张注定不全的表上**。想要好看可以切成「仅在必要时加」。

⭐ **外键会被检查**：指向不存在的表或列、两边列数对不上，在真库上都是建表直接失败，这里先告诉你。看不懂的行会**明确列出来**，不会静默丢掉。还能一键导出 **Mermaid ER 图代码**。全程本机完成，DDL 不上传。

⭐⭐ **索引与 CHECK 约束也一起搬过去了。**早先这两样是被跳过的 —— 索引**静默消失**、带名字的 CHECK 还会报一句看不懂的错。现在都建模了，而且**跨库时的位置差异会告诉你**：MySQL 允许把索引写在建表语句里，而 PostgreSQL / SQLite / SQL Server **都不允许**，必须写成表后面单独的 `CREATE INDEX` —— 工具自动换位置，并在报告里说明「内容不变，只是位置变了」。

⭐⭐⭐ **搬到 MySQL 时会提醒你一件很容易踩的事**：MySQL 要 **8.0.16 以上**才真正强制 CHECK 约束，更早的版本是「解析后忽略」（官方手册的原话就是 parsed and ignored）—— 建表会**成功**，约束**完全不生效**，而且**没有任何警告**。

⭐ **CHECK 表达式里的标识符引号会按目标库换**（MySQL 的反引号在 PostgreSQL 里是非法字符，不换就直接语法错），而**字符串里的内容一个字都不动**。⚠ 各家的函数名与运算符不完全一致，工具会提醒你人工过一眼 —— 表达式搬运不保证完美，这一点不瞒你。

⭐⭐⭐ **生成的建表语句是在真数据库上跑通过的，不只是"看起来对"。**工具自带两个端到端验证：把产物拿到**真 SQLite** 与**真 PostgreSQL 17.5** 上建表，再反查库里的结构和索引对不对，最后**插几条违规数据看约束有没有真的拦住**（建表成功不等于约束在）。⭐ 每条拒绝都配一条「合法数据插得进去」的对照，免得把别的毛病误当成约束生效。

⭐⭐ **这一轮真库当场抓到一个此前完全看不出来的缺陷**：MySQL 的 `DEFAULT 0` 搬到 PostgreSQL 的布尔列上，PG **直接拒绝建表**（布尔列不接受数字做默认值）—— 而这个错误在任何"自己检查自己"的测试里都发现不了。现在默认值会**按目标数据库改写**：PostgreSQL 的布尔写 `FALSE`/`TRUE`，SQL Server 取当前时间写 `GETDATE()`（它没有 `NOW()`）；而**非布尔列上的 0 原样保留** —— 不是每个 0 都是布尔。

⭐⭐⭐ **还能拿两份结构对一对，直接给你迁移脚本（ALTER）。**左边粘现在的表结构、右边粘改成什么样，工具算出差异并生成 `ALTER TABLE` 语句。⭐ 这比的是**结构语义不是文本**：换个缩进、调个列顺序**不算变更**（拿通用的文本对比工具比两份 DDL，光是格式差异就够你看半天）。

⭐⭐⭐ **动手之前，先告诉你哪几步会丢数据。**删表、删列会**永久删除**；把长度收窄（比如 varchar(100) 改成 varchar(50)）会**截断已有内容**；把可空列改成非空，**只要表里有一行是 NULL 就会直接失败**。⛔ 这些语句本身语法完全正确 —— 在空库上跑得好好的，到了有数据的库上才出事。所以它们被单独列在最前面，和普通变更分开。

⭐⭐ **SQLite 做不到的，工具直说，不硬凑。**SQLite 没有 `ALTER COLUMN`（改类型、改可空、改默认值一概不行）—— 遇到这类变更，工具**不会**硬拼一句让你跑去报语法错，而是明确告诉你要走「建一张新表 → 拷数据 → 删旧表 → 改名」这套。

⭐⭐⭐ **外键的变化也看得见了 —— 包括最容易被忽略的那一种。**早先只比表、列、索引和 CHECK：把外键删掉、或者把 `ON DELETE` 从 `CASCADE` 改成 `SET NULL`，工具都会说「没有差异」。而后者是**删父行时子行跟不跟着删**的完全相反的行为。现在这些都会被检出，而且**说清会发生什么**：改成 `CASCADE` 之后，删掉父表的一行，这张表里对应的行**会跟着一起被删掉**（标成危险）；改成 `SET NULL` 则是子行还在、外键列被置空（只是提醒）—— 两个方向不是一个级别。

⭐⭐ **改外键行为要先删再建，而删不掉就一句都不生成。**如果原来的外键在建表语句里没写名字，数据库会自动起一个名 —— 这里指不出来，删不掉。⛔ 这时候如果只发一条 `ADD`，那个约束还在库里：要么直接报错，要么真给同一对列挂上**两个**外键。所以工具**一句都不发**，改为告诉你先去库里查出实际的约束名。

⭐ 这些行为描述**是拿真 PostgreSQL 跑出来验过的**：`SET NULL` 时删父行，子行还在、外键列被置空；换成 `CASCADE` 后再删，子行真的跟着没了。

⭐⭐⭐ **表的先后顺序会被排过了 —— 这以前是错的。**带外键的表有先后：父表还没建出来，子表那句 `REFERENCES` 就指了个空。之前工具是照你粘进来的顺序原样导出的，子表排在前面时，这份 DDL 在真 PostgreSQL 上会停在 `relation "…" does not exist` —— ⛔ 而那句语法完全正确，在空库上你甚至看不出哪里不对。现在结果里的表按依赖排过，界面上也会直接告诉你「先建哪张、再建哪张」。

⭐⭐⭐ **外键绕成环也有办法。**A 指 B、B 又指 A 时，无论先建哪一张都不行。工具会把环上的外键从建表语句里摘出来，等所有表都建完之后用 `ALTER TABLE` 补回来，并说清是哪几张表绕在一起。

⭐⭐ **SQLite 是个例外，而且例外得刚好。**它建表时根本不去找外键指向的表（要到插数据时才校验），所以先建谁都行、环也不用拆 —— 它也确实不支持用 `ALTER` 事后加约束。两件事正好互补。这几条都在真 PostgreSQL 17.5 和真 SQLite 上跑过，不是照着文档写的。

⭐ **自己指向自己的表不算环**（上下级这类结构），同一条建表语句里就能建出来，不会被白拆一句。

⭐⭐⭐ **可以直接看图了，而且这张图的横排就是建表顺序。**点「ER 图」把结构画出来：最左边一列是不依赖任何表、可以最先建的，越往右越晚 —— 从左往右读一遍就是可以照着敲的顺序。表框可以拖着挪位置，能平移、缩放，也能导出 PNG。

⭐⭐⭐ **连线接在具体的列上。**两条外键都指向同一张表时，接到表框中间就完全分不出哪条是哪条 —— 而这恰恰是看 ER 图时最想知道的事。列太多被折起来的时候，线会接到表名上，不会硬指一行不相干的列。

⭐⭐ **外键成环在图上一眼看得见**：环上的表描红边，会被拆成表后 `ALTER` 的那一条画成红虚线 —— 图上标红的那条，正是导出的 DDL 里被拆出去的那条。自己指向自己的表画成紫色绕圈，不描红（它不是环，不用拆）。

⭐⭐⭐ **外键会被真正检查了 —— 这以前只查了「列名对不对得上」。**外键不是两个列名对上就行：被引用的那组列**必须是唯一的**（主键或唯一约束），否则一个值对上多行，数据库不知道该指哪一行。⛔ 之前工具对这种情况报「没问题」，而真 PostgreSQL 建表直接失败；真 SQLite 更麻烦 —— 表建得出来，等你插数据时才报 `foreign key mismatch`。⭐ 还有一条特别隐蔽：**复合主键 `(a, b)` 的前缀 `a` 不算唯一**。

⭐⭐⭐ **两边的类型也会检查，而且这件事有方向。**长度或精度不同没关系（`VARCHAR(50)` 指向 `VARCHAR(20)` 是通的），换一类才不行。⭐ 反直觉的是：定点小数指向双精度**通**，反过来**不通**；布尔与整数不通；UUID 指向字符串不通（这个误接很常见）；日期与时间戳互通，而「时间」与谁都不通。这张对照表不是照文档抄的，是在真 PostgreSQL 17.5 上把 18 × 18 = 324 组组合逐对试出来的。

⭐ **每个库的口径分开说**：PostgreSQL 上算错误（逐对实测过）；SQLite 不检查类型，算提醒（但这份结构搬去别的库就建不出来）；MySQL 与 SQL Server 本机没有，只提醒，并明说没验过。

⭐⭐ **ER 图上也看得见**：建不出来的那条线画成橙色并打一个叉，一眼就知道是哪一条。

⭐⭐⭐ **表的先后顺序会被排过了 —— 这以前是错的。**带外键的表有先后：父表还没建出来，子表那句 `REFERENCES` 就指了个空。之前工具是照你粘进来的顺序原样导出的，子表排在前面时，这份 DDL 在真 PostgreSQL 上会停在 `relation "…" does not exist` —— ⛔ 而那句语法完全正确，在空库上你甚至看不出哪里不对。现在结果里的表按依赖排过，界面上也会直接告诉你「先建哪张、再建哪张」。

⭐⭐⭐ **外键绕成环也有办法。**A 指 B、B 又指 A 时，无论先建哪一张都不行。工具会把环上的外键从建表语句里摘出来，等所有表都建完之后用 `ALTER TABLE` 补回来，并说清是哪几张表绕在一起。

⭐⭐ **SQLite 是个例外，而且例外得刚好。**它建表时根本不去找外键指向的表（要到插数据时才校验），所以先建谁都行、环也不用拆 —— 它也确实不支持用 `ALTER` 事后加约束。两件事正好互补。这几条都在真 PostgreSQL 17.5 和真 SQLite 上跑过，不是照着文档写的。

⭐ **自己指向自己的表不算环**（上下级这类结构），同一条建表语句里就能建出来，不会被白拆一句。

⭐⭐⭐ **可以直接看图了，而且这张图的横排就是建表顺序。**点「ER 图」把结构画出来：最左边一列是不依赖任何表、可以最先建的，越往右越晚 —— 从左往右读一遍就是可以照着敲的顺序。表框可以拖着挪位置，能平移、缩放，也能导出 PNG。

⭐⭐⭐ **连线接在具体的列上。**两条外键都指向同一张表时，接到表框中间就完全分不出哪条是哪条 —— 而这恰恰是看 ER 图时最想知道的事。列太多被折起来的时候，线会接到表名上，不会硬指一行不相干的列。

⭐⭐ **外键成环在图上一眼看得见**：环上的表描红边，会被拆成表后 `ALTER` 的那一条画成红虚线 —— 图上标红的那条，正是导出的 DDL 里被拆出去的那条。自己指向自己的表画成紫色绕圈，不描红（它不是环，不用拆）。

⭐⭐⭐ **外键会被真正检查了 —— 这以前只查了「列名对不对得上」。**外键不是两个列名对上就行：被引用的那组列**必须是唯一的**（主键或唯一约束），否则一个值对上多行，数据库不知道该指哪一行。⛔ 之前工具对这种情况报「没问题」，而真 PostgreSQL 建表直接失败；真 SQLite 更麻烦 —— 表建得出来，等你插数据时才报 `foreign key mismatch`。⭐ 还有一条特别隐蔽：**复合主键 `(a, b)` 的前缀 `a` 不算唯一**。

⭐⭐⭐ **两边的类型也会检查，而且这件事有方向。**长度或精度不同没关系（`VARCHAR(50)` 指向 `VARCHAR(20)` 是通的），换一类才不行。⭐ 反直觉的是：定点小数指向双精度**通**，反过来**不通**；布尔与整数不通；UUID 指向字符串不通（这个误接很常见）；日期与时间戳互通，而「时间」与谁都不通。这张对照表不是照文档抄的，是在真 PostgreSQL 17.5 上把 18 × 18 = 324 组组合逐对试出来的。

⭐ **每个库的口径分开说**：PostgreSQL 上算错误（逐对实测过）；SQLite 不检查类型，算提醒（但这份结构搬去别的库就建不出来）；MySQL 与 SQL Server 本机没有，只提醒，并明说没验过。

⭐⭐ **ER 图上也看得见**：建不出来的那条线画成橙色并打一个叉，一眼就知道是哪一条。

⭐⭐⭐ **ER 图上可以直接连线建外键了。**切到「连线建外键」模式，从外键列（子表）拖到被引用的列（父表）松手即建。⭐ 连不连得上、为什么，松手时当场告诉你 —— 判的和下面校验报告是**同一套规则**（被引用列必须唯一、复合主键前缀不算唯一、两边类型有方向地相容），不是另一套画布专用的宽松版。

⭐⭐ **连成的线会以 ALTER TABLE 写回输入框** —— 重新解析也不丢；目标库对应的写法也一并给出。SQLite 源库会明说：它的 ALTER 语法没有「加外键」这句，写不回去。⭐ 连错了可以一步步撤销；你在连线之后自己改过输入框的话，那句 ALTER 不会被盲删，会提醒你自己处理。

⭐⭐ **ER 图的连线会绕开挡路的表框了。**表一多，跨层的外键线会从不相干的表框上碾过去 —— 读图的人分不清这条线连的是被穿的表还是后面的表。现在挡路的线会自动绕 1~2 个弯（从表框之间的走廊走），绕不干净的极端结构也不假装避开了。⭐ 线的两端仍然精确接在列上，拖动表框后绕行实时重算。

⭐ **手机上可以双指缩放 ER 图了。**双指开合缩放、双指平移拖动画布，捏哪儿放大哪儿；单指拖表、连线照旧。

⭐⭐⭐ **现在可以从一张空白表开始，全程在图上画出一套库。**「从零建表」一键起步；画布上加表、加列、连线建外键，每一步都实时写回输入框的 DDL —— 图不是另一份文件，它就是你那份建表语句本身，重新解析一步都不丢，连错加错可以一步步撤销。

⭐⭐ **「加列」的边界是真库测出来的**：SQLite 不允许用 ALTER 加唯一列（语法级拒绝，工具会明说写不回）；⭐ 「NOT NULL 列必须带默认值」这条限制其实是**按表里有没有数据判的** —— 空表能加，有数据才拒（真 PostgreSQL 与真 SQLite 都实测过），工具会在你勾了必填时提前提醒。

⭐⭐ **点一条线就能看这条外键的一切**：两端各是哪列、在不在环上、真库上建不建得出来；画上去的线还能当场改「删父行时子行怎么办」（ON DELETE / ON UPDATE 五种动作），或者点名删掉 —— 改动实时写回输入框。来自你粘的 DDL 的线是只读的：工具不动你写的字。

⭐⭐ **外键动作也按目标库校准**（这以前是跨库原样照搬的）：SQL Server 没有 RESTRICT（自动改写成行为一致的 NO ACTION）；MySQL 的 InnoDB 不认 SET DEFAULT（写上去建表直接被拒 —— 生成时去掉并在报告里明说，因为删父行时子行的行为变了）。⭐ PostgreSQL 与 SQLite 的五种动作都是真库实测过的，CASCADE 是真的会级联删除。

⭐ **点开一条建不出来的线，原因就写在弹窗里**（被引用列不唯一 / 类型不相容 —— 和校验报告一字不差），不用再回主界面找。⭐ 加列表单补齐：定点小数可以填精度与小数位；默认值一格会自动处理引号（文本加引号、数字和「当前时间」不加）；SQLite 上「默认值取当前时间」的列会提醒你 —— 表里已有数据时那句 ALTER 会失败（真库实测，空表能加）。无需注册、无需安装软件，打开网页即可使用，处理全程在浏览器本机完成，文件不上传服务器。