CSV 转 SQL

CSV 转 SQL 做的事情很具体：拿一份用逗号分隔的表格文本，输出能在关系型数据库里复现这份数据的 SQL 语句。通常会产出一段 `CREATE TABLE`（按 CSV 表头定义字段）和一组 `INSERT`（把每一行数据放进表里）。这份 SQL 是一份“可读、可改、可跑”的起点稿，不是经过 DBA 评审、已经和生产数据库对齐的迁移脚本。把它当“草稿”看，才不会把后面的事做反。

为什么会需要这一步转换

CSV 是电子表格、导出数据、临时倾出文件的通用语言；数据库说的是 SQL。当一份行列文件要变成可以被其它查询 JOIN 的真实表时，就得有人来搭这座桥。给五十行手敲 INSERT 既费时间又容易把引号写错；用工具自动生成一版、再人工审阅修改，往往比纯手写快、也更不容易出现“某一行字符串没转义”的低级错。

工具不得不“猜”的时候，遵循哪些规则

CSV 没有 schema、没有类型系统，转换工具必须替你做几个决定。提前知道这些规则，审查输出会快很多。

• 字段名来自表头行：含空格、连字符或保留字时会被加引号变成合法标识符。
• 类型按前几行采样推断：整列都是数字就猜整数，都是小数就猜浮点，其它情况一律退回到文本。
• 空单元格默认变成 `NULL`，除非整列明显就是文本而且确实存在“真空字符串”这种合法值。
• 值里的单引号会按 SQL 规则用两个单引号转义：`O'Brien` 会变成 `'O''Brien'`，避免插入语句被引号截断。
• 数字和布尔不加引号，其它一律按字符串字面量加引号。原本看起来像数字但应当当作文本存（例如订单号 `00123`）的列，要在审查阶段显式标出来。

一句话原则：工具保证生成的 SQL“能编译”，不保证推断出来的 schema 和真实应用对齐。`CREATE TABLE` 的最终决定权永远在审稿的你手上。

如何使用这个工具

1. 先在 CSV 转 SQL 中准备一份有代表性的需要生成建表或插入 SQL 的 CSV 行数据，不要一开始就处理最大或最敏感的真实内容。
2. 执行处理流程并生成按照 CSV 表头和行值映射出来的 SQL 草稿后，优先检查表头清洁度、分隔符准确性、引号、空单元格、推断列类型和行一致性，再判断结果是否真的可用。
3. 只有当结果已经适合用于导入审查、Mock 数据准备、迁移规划和表格到数据库交接，并且不再触发这条风险提醒时，才复制或下载输出：如果 CSV 里存在异常分隔符或带引号逗号，必须先修正，再信任生成出来的 SQL。

CSV 转 SQL 示例

这个 CSV 转 SQL 示例使用有代表性的需要生成建表或插入 SQL 的 CSV 行数据，展示生成后的按照 CSV 表头和行值映射出来的 SQL 草稿，便于你先确认表头清洁度、分隔符准确性、引号、空单元格、推断列类型和行一致性，再把同样设置用于真实输入。

示例输入

[{"id":1,"name":"Ada","active":true}]

预期输出

CREATE TABLE items (id INTEGER, name TEXT, active BOOLEAN);
INSERT INTO items (id, name, active) VALUES (1, "Ada", TRUE);

一份四行 CSV 与对应的 SQL

-- CSV 输入
id,name,price,inStock
1,Notebook,4.50,true
2,Pen,1.20,false
3,Mug,7.00,true

-- 生成的 SQL（草稿）
CREATE TABLE products (
  id        INTEGER,
  name      TEXT,
  price     REAL,
  inStock   BOOLEAN
);

INSERT INTO products (id, name, price, inStock) VALUES (1, 'Notebook', 4.50, true);
INSERT INTO products (id, name, price, inStock) VALUES (2, 'Pen',      1.20, false);
INSERT INTO products (id, name, price, inStock) VALUES (3, 'Mug',      7.00, true);

注意：生成的表里没有主键、没有 `NOT NULL` 约束、没有索引。工具不会替你“顺手补上”这些——它们是只有你能决定的契约。

什么场景下 CSV 转 SQL 最合适

这一步转换最划算的场景，是目标本来就是“草稿数据库 / 一次性导入 / 方案讨论的起点”——任何需要快速回答“这份 CSV 大概能不能变成一张表”的位置。

• 把一份小型参考数据（国家、币种、商品类目）灌进一个全新的开发数据库。
• 拿产品/QA 维护的表格作为测试 fixture 的起点，先生成 SQL 再调整。
• 和同事讨论 schema：“这是 CSV 的样子，这是它会生成的 SQL，咱们要改哪里？”
• 在 SQLite 或 Postgres 沙盒里跑一次性导入：5 分钟内把数据变成可 SQL 查询的形式。
• 评估第三方导出的数据能不能塞进现有表结构：先用 CSV 推一版草稿 schema，再去和现有 DDL 做 diff。

在执行生成 SQL 前应当处理的几类坑

生成 SQL 在生产环境出事，多数不是工具错了，而是“拿生成稿当成品”。下面这些是把 SQL 粘进 `psql`、`sqlite3` 之前最值得复核的几类情况。

• 表头与保留字撞名（`order`、`user`、`select`）：不同数据库方言的转义符不一样，且常常在迁移到另一种数据库时才暴露。
• 类型不纯的列：原本应是数字的列里出现一行 `N/A`，整列就会被推成 `TEXT`，后续所有数值运算 SQL 都会跟着出错。
• 没有约定格式的日期字符串（如 `03/04/2024`）：在草稿里先按 `TEXT` 落地，避免数据库按错误时区/语言解析。
• 超长的单条 INSERT 列表：大多数数据库更适合用多值 `VALUES (...)`、`COPY`（Postgres）、`.import`（SQLite）等批量方式，而不是几千条独立 INSERT。
• 未包事务：大批量 INSERT 不包在事务里，一旦中途失败就是部分提交，回滚成本极高。在执行生成的脚本前手动加上 `BEGIN; ... COMMIT;`。
• 直接对生产库执行：哪怕数据看起来很无害，也务必先在 Staging 副本上跑一遍。

CSV 转 SQL 与相邻的“数据加载”方案对比

使用注意

• 复用按照 CSV 表头和行值映射出来的 SQL 草稿前，先检查表头清洁度、分隔符准确性、引号、空单元格、推断列类型和行一致性。
• 如果 CSV 里存在异常分隔符或带引号逗号，必须先修正，再信任生成出来的 SQL。
• 当结果会影响生产工作或客户可见内容时，应保留原始需要生成建表或插入 SQL 的 CSV 行数据以便回退和核对。

CSV 转 SQL 参考说明

CSV 转 SQL 的参考说明应始终围绕需要生成建表或插入 SQL 的 CSV 行数据、生成的按照 CSV 表头和行值映射出来的 SQL 草稿，以及用于导入审查、Mock 数据准备、迁移规划和表格到数据库交接前必须确认的检查点。

• 输入重点：需要生成建表或插入 SQL 的 CSV 行数据。
• 输出重点：按照 CSV 表头和行值映射出来的 SQL 草稿。
• 复核重点：表头清洁度、分隔符准确性、引号、空单元格、推断列类型和行一致性。

参考资料

• RFC 4180: Common Format and MIME Type for CSV Files
• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax