JSON 转 SQL 建表语句（CREATE TABLE）
免费在线 JSON 转 SQL DDL 工具，纯前端本地处理，数据不上传服务器。粘贴 JSON 自动生成 CREATE TABLE，类型按数据实际范围推断（INT/BIGINT/DECIMAL/VARCHAR），支持 MySQL / PostgreSQL / SQLite 方言。
Ctrl / Cmd + Enter 可立即生成。
为什么不用把数据传到服务器上
同类工具（比如 sqlizer.io）是服务端的——你得先把 JSON 传上去才能转换。
但建表语句本身就泄露业务结构：字段名往往把业务逻辑说得清清楚楚，
比如 is_vip、refund_deadline、supplier_cost。
这个工具全部在浏览器里跑，一行数据都不出本机。 断网也能用——可以试试。
类型是怎么推出来的
按数据的实际范围推，不拍脑袋：
- 整数看范围：放得下 32 位就给
INT，放不下才BIGINT -
小数看精度：扫出整数部分最多几位、小数最多几位，生成
DECIMAL(p,s)，而不是一律给DOUBLE -
字符串看长度：取 16 / 32 / 64 / 128 / 255 档，超过就给
TEXT - 布尔 →
BOOLEAN（MySQL 没有真正的布尔类型，用TINYINT(1)） - 嵌套的对象和数组 →
JSON列，不拆表
同一字段里出现多种类型（一会儿数字一会儿字符串）时，退回
TEXT——SQL 的一列只能有一种类型，退回文本最不容易丢信息。
这种情况会在输出里用注释标出来。
它不会替你猜日期
"2024-03-01" 会老老实实生成 VARCHAR，不会变成 DATE。
因为「看起来像日期的字符串」太多了：版本号、批次号、日期区间…… 猜错的话，导入数据时才会炸，而且报错信息跟日期毫无关系， 排查起来很痛苦。
需要 DATE 的话，生成后手动改一下就行——这本来就是个起点，不是终稿。
NOT NULL 是怎么判断的，可信吗
某列在所有样本里都存在且非 null，才标 NOT NULL。
⚠️ 样本少的时候这个推断很不可靠——3 行数据里都有值，不代表线上不会有空。 输出开头会写明是基于几行样本推出来的，上线前按业务再核对一遍。
输入是一个对象、里面每个键都是数组，会怎样
比如 { "users": [...], "orders": [...] }，
会每张表生成一条 CREATE TABLE，表名直接用键名。
这是「一次导出多张表」的常见形状。
其他情况（单个对象、对象数组）都只生成一张表。