工具用的顺手吗？
你的反馈能帮助我们做得更好
将SQL表结构定义（DDL）语句解析并转换为结构化的JSON数据格式。
读取单条 MySQL CREATE TABLE 的字段定义。字段属性、约束及表选项以 SQL 文本保留；不会生成 JSON Schema 或执行 SQL。
概览
了解工具能解决的问题、计算或处理逻辑，以及数据边界。
把一条按行排版的 CREATE TABLE 建表语句贴入左侧后，右侧会立即生成一个 JSON 对象。对象顶层只有 tableName 和 fields：前者是识别到的表名，后者是字段数组。每个字段只包含 name、type、length 三项，因此它更适合制作轻量字段清单，而不是完整保存数据库模式。
页面不会连接数据库、创建表或读取表中数据，也不会把 INSERT 记录转换成业务 JSON。NOT NULL、DEFAULT、AUTO_INCREMENT、主键、唯一键、普通索引、外键、注释、字符集和存储引擎都不会出现在结果字段中。输入变化后结果随之重算，可复制 JSON，也可下载为 ddl-converted.json。
| 位置 | 类型 | 含义 |
|---|---|---|
tableName | 字符串 | CREATE TABLE 后识别到的第一个简单表名；未匹配时显示 unknown_table。 |
fields | 数组 | 按输入行顺序收集的字段摘要。 |
name / type | 字符串 | 字段名与紧随其后的第一个类型单词，保留输入中的字母大小写。 |
length | 字符串或 null | 只识别紧跟类型的单个整数括号，例如 VARCHAR(50) 得到 "50"；没有这种长度时为 null。 |
识别过程按换行逐项读取，因此建议一行只写一个字段，并使用字母、数字或下划线组成的简单标识符；MySQL 风格的反引号可以保留。表名应直接跟在 CREATE TABLE 后，不要加入数据库名前缀、TEMPORARY 或 IF NOT EXISTS。一个输入框只放一条建表语句，多个表不会被拆成多个 JSON 对象。
包含 KEY 的行会被略过。若写成 id INT PRIMARY KEY，这一整行可能不会进入 fields；把 id INT 与单独的 PRIMARY KEY (id) 分成两行，字段会保留，而约束行会忽略。DECIMAL(10,2) 之类含两个数字的精度写法只能保留类型 DECIMAL，length 会是 null；DOUBLE PRECISION 也只会取第一个类型单词。
JSON 是一种数据交换语法，能够用对象、数组、字符串、数字、布尔值和 null 组织数据；JSON Schema 则是另一套用来描述并验证 JSON 实例的词汇体系。本页输出符合 JSON 的对象与数组结构，但没有 $schema、properties、required 等 JSON Schema 关键字，也没有把 SQL 类型映射成 JSON 数据类型。
因此，输出可以作为字段盘点、文档草稿或后续脚本的中间数据。若目标是 OpenAPI 模型、表单校验规则、ORM 模型或可执行迁移，还需按目标规范补充类型映射、必填状态、默认值、键与关联关系，不能直接把当前结果当作完整定义。
指南
按步骤完成操作，并通过示例核对输入与结果。
保留一条 CREATE TABLE，让表名直接跟在关键字后，并把每个字段放在独立行。若字段使用内联 PRIMARY KEY，先改成单独的约束行。
在“SQL DDL 输入”区粘贴文本；也可点“示例”查看适合的排版。页面会随文字变化生成结果，不需要另外提交。
先看 tableName 是否正确，再逐项检查 name、type 与 length。若出现 unknown_table、空数组或字段缺失，应先调整输入格式。
确认摘要与原 DDL 一致后，可复制右侧 JSON，或下载 ddl-converted.json 交给后续脚本处理。
例如输入：
CREATE TABLE `users` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`nickname` VARCHAR(50) NOT NULL,
`created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
);结果为：
{
"tableName": "users",
"fields": [
{ "name": "id", "type": "INT", "length": "11" },
{ "name": "nickname", "type": "VARCHAR", "length": "50" },
{ "name": "created_at", "type": "TIMESTAMP", "length": null }
]
}这个例子也展示了信息取舍：NOT NULL、AUTO_INCREMENT、默认值和主键没有写入 JSON，只有表名与字段的基础三项被保留。
场景
查看这项工具在不同工作与生活流程中的用法。
后端开发者可先把单表 DDL 转成字段数组，再人工补充字段含义、是否必填和示例值，作为接口评审的起点。
评审人员可复制字段名与基础类型，检查命名风格、字段顺序和明显的长度差异；键、默认值与关联关系仍回到原 DDL 核对。
需要遍历字段名称的脚本可以读取 fields 数组，生成简单表头、占位文档或映射模板，再由开发者补齐业务规则。
问答
集中解答高频疑问与容易混淆的问题。
表名必须直接跟在 CREATE TABLE 后。TEMPORARY 可能导致未匹配，IF NOT EXISTS 可能让 IF 被当成表名，数据库名前缀则可能只留下前缀部分；双引号和方括号标识符也不适合当前规则。整理成 CREATE TABLE users 或反引号形式后再试。
先检查该字段是否与 PRIMARY KEY 写在同一行。把字段定义单独保留一行，再把主键声明移到另一行；页面会提取字段行并跳过键声明行。
不适合。当前结果围绕单条、按行排版的 CREATE TABLE 生成一个对象；ALTER TABLE 不会形成完整表结构，多条建表语句也不会输出多个独立对象，应逐表转换。
length 只接收一个整数参数的形式，例如 VARCHAR(50)。精度与小数位包含逗号，不属于当前长度提取范围；需要保留 10,2 时，应在导出后自行补充。
须知
使用前了解适用范围、结果限制与必要提醒。
输出是简化的文本提取结果，不是 SQL 语法校验报告，也不能证明建表语句能在某个数据库版本中执行。即使输入不完整，页面仍可能生成结构合法但语义不完整的 JSON。
推荐
查找相关工具、专题与可用的 API 能力。