企业官网建设流程全解析

• 文档
• 教程
• 知识库

TRUNCATE是 PostgreSQL 中清空整张表数据的高效手段，但很多开发者会发现：用serial/bigserial做主键的表被清空后，新插入的数据 ID 仍然从上次停下的数字继续递增，而不是从 1 重新开始。本文从 til 仓库中 Restarting Sequences When Truncating Tables 这篇笔记出发，讲清序列为何不自动重置、TRUNCATE ... RESTART IDENTITY的正确用法，以及手动重置序列、CASCADE级联清空等配套实战方案。

问题现象：TRUNCATE 之后 ID 继续往上数

PostgreSQL 的truncate是一个快速清空表数据的特性。当你对一张带serial主键的表执行truncate后，数据虽然被清掉了，但随后插入的新记录往往会发现 ID 不是从 1 开始，而是接着之前的值继续递增。

原因在于：serial主键背后是一张独立的序列（sequence）对象，而truncate默认并不会重置它。序列记录着"下一个要发放的 ID"，它只负责发号，并不关心表中的数据是否还存在。因此清空表之后，序列仍停留在之前的推进位置，新插入的行自然就接着往下编号。

仓库中的另一篇笔记 Restart A Sequence 明确指出了这一现象：在开发或测试环境中对表做清空等破坏性操作时，主键 ID 的序列"just keeps plugging along from where it last left off"（只会从上次停下的地方继续推进）。

解决方案：给 TRUNCATE 追加 RESTART IDENTITY

与其清空后再手动处理序列，不如直接告诉 `truncate"把关联的序列一并重置"。在原文档中，核心写法如下：

truncate pokemons, trainers, pokemons_trainers restart identity;

只要在truncate语句末尾追加restart identity，PostgreSQL 就会在清空表数据的同时，将任何关联的序列重置回1。此后向这些表插入新记录，主键 ID 会重新从 1 开始。

语法要点与可选子句

TRUNCATE的完整语法可以概括为：

TRUNCATE [ TABLE ] 表名 [, ...] [ RESTART IDENTITY | CONTINUE IDENTITY ] [ CASCADE | RESTRICT ]

围绕本文主题，各子句的含义如下：

一条truncate可以同时列出多张表（如上面的pokemons, trainers, pokemons_trainers），PostgreSQL 会一次性将它们的数据全部清空，并统一处理各自关联的序列。

一个可复现的完整示例

假设有一套宝可梦数据模型，pokemons_trainers通过外键关联pokemons与trainers，三张表都用serial主键：

create table pokemons ( id serial primary key, name text not null ); create table trainers ( id serial primary key, name text not null ); create table pokemons_trainers ( id serial primary key, pokemon_id int references pokemons(id), trainer_id int references trainers(id) );

先插入几条数据，让 ID 推进到一定位置：

insert into pokemons (name) values ('Pikachu'), ('Charizard'), ('Squirtle'); insert into trainers (name) values ('Ash'), ('Misty'); insert into pokemons_trainers (pokemon_id, trainer_id) values (1, 1), (2, 1), (3, 2);

此时三张表的序列last_value已经推进到 3 / 2 / 3 左右。接下来执行带restart identity的截断：

truncate pokemons, trainers, pokemons_trainers restart identity;

随后再插入一行测试数据：

insert into pokemons (name) values ('Bulbasaur') returning id;

返回的id是1，而不是 4——序列已经被成功重置。

为什么序列不随事务回滚或清空而重置？

序列这种"自顾自往前走"的行为并非偶然。仓库中的 Sequence Side-Effect When Rolling Back Inserts 一文用实验验证了序列的底层机制：

1. 新建一张带bigserial主键的表books，此时books_id_seq的last_value为 1、is_called为f（尚未发过号）；
2. 在一个事务里插入 3 行，books_id_seq的last_value推进到 3；
3. rollback回滚事务后，表books恢复了空表，但books_id_seq的last_value仍然停留在 3。

该笔记给出的解释是：序列的使用发生在事务隔离之外。多个并发事务可能同时需要向序列取号，为了让它们不必互相阻塞，序列始终可以被访问。代价就是序列的last_value只会不断向前推进，一旦事务回滚就会留下空洞（gap）。

这也从侧面印证了：序列和表数据是两套独立的状态，任何只清数据不清序列的操作（包括默认的TRUNCATE、普通的DELETE再回滚），都不会让 ID 自动归零。restart identity正是针对这一特性提供的"一站式"解决方案。

备选方案一：手动重置序列

如果你不希望truncate改动序列，或者只想单独把某个序列拉回某个值，也可以手动重置。仓库中的 Restart A Sequence 给出了ALTER SEQUENCE的写法：

alter sequence my_table_id_seq restart with 1;

执行成功会返回ALTER SEQUENCE。restart with后面的数字可以不是 1——它会把序列的下一次取值设置为任意指定值，适合"希望清空后从某个特定 ID 继续"的场景。

需要提醒的是，serial主键背后的序列命名遵循"表名_列名_seq"的约定。例如pokemons表的id列对应的序列叫pokemons_id_seq。如果你重命名过表，序列不会跟着自动改名，可以参照 Renaming A Sequence 手动执行alter sequence ... rename to ...保持命名一致；但无论序列叫什么名字，restart identity都能定位并重置它，这比手工维护序列名更省心。

备选方案二：直接 DELETE，但要知道代价

面对"清空整张表"的需求，另一个常见选择是DELETE FROM 表名（不带 WHERE）。仓库中的 Truncate All Rows 对比了两者：

delete from pokemons; -- DELETE 151 truncate pokemons; -- TRUNCATE TABLE

结论很明确：如果目的就是把表清空，TRUNCATE优于DELETE——它直接删除数据而无需逐行扫描，速度更快，且会立即释放磁盘空间。当然，TRUNCATE也意味着更小的"后悔余地"（不可按条件部分删除、不走行级触发器等），大规模清空时建议像 Truncate Tables With Dependents 中提醒的那样，放进事务里执行，以便在必要时回滚。

备选方案三：处理外键依赖（CASCADE）

现实中的表很少孤立存在。如果一张表被其他表通过外键引用，直接truncate它会报错：

ERROR: cannot truncate a table referenced in a foreign key constraint

仓库中的 Truncate Tables With Dependents 给出了两种对策：

-- 一次性截断相互关联的多张表 truncate A, B; -- 或使用级联，自动把依赖表一起清空 truncate A cascade;

注意truncate A cascade执行时 PostgreSQL 会返回NOTICE: truncate cascades to table "B"，提醒你哪些表被波及。当这种"清空主表并重置所有相关自增 ID"的需求出现时，将cascade与restart identity组合使用：

truncate A cascade restart identity;

即可一次完成"级联清空 + 全链路序列归零"。

进阶思考：serial 的现代替代方案 identity 列

既然serial主键的序列管理如此"黏人"，仓库中的 Generate Modern Primary Key Columns 指出：PostgreSQL 社区早已不再推荐用serial定义新表的主键，而是推荐使用标准 SQL 的identity 列：

create table books ( id int primary key generated always as identity, title text not null, author text not null, created_at timestamptz not null default now(), updated_at timestamptz not null default now() );

identity 列在底层同样依赖序列，因此truncate ... restart identity对它同样生效；但它把序列的创建、依赖关系和权限管理与列本身绑定得更规范，规避了serial在 schema、依赖和权限管理上的"weird behaviors"。对于正在设计新表的读者，建议直接使用 identity 列；对于存量serial表，restart identity依然是清空后重置 ID 的最直接手段。

小结

• 默认的TRUNCATE只清数据、不动序列，serial主键清空后 ID 会继续递增，因为序列是独立于表数据推进的；
• 在TRUNCATE末尾追加RESTART IDENTITY，即可在清空数据的同时把所有关联序列重置为 1；
• 序列取值发生在事务隔离之外，回滚插入也无法让序列回退，这是设计使然（详见 Sequence Side-Effect When Rolling Back Inserts）；
• 需要手动精确控制时，可用ALTER SEQUENCE ... RESTART WITH n（参考 Restart A Sequence）；
• 面对外键依赖，CASCADE与RESTART IDENTITY可以组合使用（参考 Truncate Tables With Dependents）；
• 新项目建议用 identity 列替代serial（参考 Generate Modern Primary Key Columns）。

掌握restart identity，你就能在开发、测试环境里放心地反复清空并重灌数据，不必再为"ID 越数越大"而烦恼。

• 文档
• 教程
• 知识库