一、加字段：最安全的那个

加字段是一句话的事。演示里给访客表加了个 dept。 加完之后字段列表多了一个，但老记录的新字段是空的——张伟和王芳那两行的 dept 都是 None。 这不是 bug，是必然：那两行写进去的时候，这个字段还不存在。

所以要补数据。补的办法是跑一遍更新，按 gid 一行一行填。加字段的工时不在加，在补。

二、改字段名：错不在改

改字段名本身也是一句话。演示里把 purpose 改成 reason，改完字段列表就变了。 问题是之后：用旧名字查会报 no such column: purpose。 而在真实项目里，引用旧名字的地方不止一处：工作流节点的入参、提示词里的字段名、下游代码节点、 看板配置、导出报表。

所以改字段名之前要搜一遍：这个字段名出现在哪几个地方？全部改完再改表。 顺序反了就是事故：先改表，那些引用全部静默失败——链照跑，日志照绿，值是空的。

三、改字段类型：只能重建

演示里试了直接改类型，sqlite 报语法错——它不支持。 标准做法三步：建新表 → 拷数据 → 删旧表改名。 演示里跑完了，两行数据还在。 平台上看起来简单些（点一下选新类型），但底下一样是重建。历史数据要么转换要么丢。

文本改整数，里面存着「abc」，转换时就报错或者变成 0。改之前先查一遍：这一列有没有转不过去的值。

四、删表：最干脆的那个

演示里删表之后再查，报「表不存在」。删之前两行，删之后连结构都没了。 平台的「删除数据表」按钮不给撤销。 点之前确认三件事：这张表被哪个工作流引用、有没有备份、能不能重建。 第一件最容易被忽略。表被删了，引用它的工作流不会报错，只会在跑到那一步时失败。 所以删表之前先在工作流里搜表名。

第三件也值得想：能不能重建，取决于你是否记得字段结构。记不得就恢复不了。

五、备份要备两样

很多人备份只导数据。没有建表语句，光有数据也恢复不了表。 所以备份分两份：一份数据（CSV 或 JSON），一份结构（字段名、类型、默认值、必填）。 平台上的导出通常把字段名一起导出来，这算顺手解决了。 但字段类型和必填标记往往不带——那部分要自己记一笔。

一个便宜的习惯：建表那天把字段结构截图存到知识库里。两分钟的事，删表那天能救命。

六、三个动作的风险排序

排序里最反直觉的是「改字段名」比「改类型」低但比「加字段」高很多。 因为改类型你会有心理准备，改字段名你会觉得「就改个名」。 最危险的操作往往是看起来最无害的那个。

七、动手 Demo：改结构、改数据、删表

一张两行的访客表，依次做四件事：加字段、改字段名、改类型、删表。 每一步之后都看一眼字段列表，看数据还在不在。

ALTER TABLE guest ADD COLUMN dept TEXT          -- 加字段：老数据空着

ALTER TABLE guest RENAME COLUMN purpose TO reason -- 改字段名
SELECT purpose FROM guest                        -- 旧名字报错

ALTER TABLE guest ALTER COLUMN phone INTEGER     -- sqlite 不支持
-- 只能重建：建新表 → 拷数据 → 删旧表 → 改名

实跑输出：

--------------------------------------------------------------------
改结构、改数据、删表
--------------------------------------------------------------------


  ① 加一个字段
  --------------------------------------------------------------------
  加之前：gid、name、phone、purpose
  加之后：gid、name、phone、purpose、dept
  老记录的新字段：张伟=None，王芳=None
  字段加了，历史数据不会自动补。 那两行的 dept 是空的。

  ② 改字段名
  --------------------------------------------------------------------
  改之后：gid、name、phone、reason、dept
  用旧名字查：no such column: purpose
  改字段名会同时打断所有引用旧名的地方：工作流节点、提示词里的字段名、下游代码、看板。
  改之前先搜一遍旧名出现在哪几个文件里。

  ③ 改字段类型
  --------------------------------------------------------------------
  sqlite 不支持直接改类型：near "INTEGER": syntax error
  标准做法是三步：建新表 → 拷数据 → 删旧表改名。
  平台上更省事，但同样要重建，历史数据要么转换要么丢。
  重建完：gid、name、phone、reason、dept，2 行

  ④ 删表
  --------------------------------------------------------------------
  删表后再查：no such table: guest
  删之前有 2 行。删之后：表不在了，数据和结构一起没了。
  平台的「删除数据表」按钮不给撤销。
  点之前确认三件事：这张表被哪个工作流引用、有没有备份、能不能重建。

  ⑤ 删表之前该备份什么
  --------------------------------------------------------------------
  不只是数据，还有结构。没有建表语句，光有数据也恢复不了。
  所以备份分两份：一份数据（导成 CSV 或 JSON），一份结构（字段名、类型、默认值）。
  平台上的做法通常是导出全部记录，把字段名一起导出。
  只导 data 不导 schema，重建时要靠记忆猜字段类型。
  ! 这一节三个操作，风险从低到高：加字段 < 改字段名 < 删表。
  加字段最安全（老数据只是空着），改字段名最阴（错不在改，在引用的地方），删表最干脆（没有撤销）。

①第一段加字段：字段列表多了一个 dept，但张伟和王芳那两行是 None。 加字段的工时不在加，在补数据。 ②第二段改字段名：改完用旧名字查直接报错。 真实项目里引用旧名的地方不止一处——工作流、提示词、代码、看板。 ③第三段改类型：sqlite 直接不支持，要重建。 演示里用建新表 → 拷数据 → 删旧表 → 改名四步走完，两行数据还在。 ④第四段删表：删之前两行，删之后连结构都没了，再查报「表不存在」。 ⑤最后那张风险排序表里，最该记的是「改字段名」——它看起来最无害，实际比加字段危险得多。

30 秒实验

1. 搜一遍你的工作流里引用了哪些字段名。改名字之前先把这张单子列出来。
2. 给每张表把字段结构（名字、类型、必填）记一份，存到知识库里。
3. 找一个你打算删的表，先查它被哪个工作流引用。查完你可能就不删了。

常见误区

1. 「改个字段名而已。」引用旧名的地方全部静默失败：链照跑、日志照绿、值是空的。
2. 「删表前导了数据就够了。」没有建表语句，光有数据恢复不了表。结构也要备。
3. 「加字段不影响老数据。」老数据的新字段是空的，那批记录要补。

会管了，下一节讲它和传统数据库到底差在哪——一条一条量，最要紧的是事务。

• ☐ （本篇完，下一篇 7.5 扣子数据库和传统数据库的区别）

相关笔记

• 使用扣子数据库：增删改查的四个坑
• 企业知识库落地存在的问题及解决思路：知识库的更新滞后
• 15 数据库基础 · 索引
• 🐦 扣子开发 AI Agent · 索引