PostgreSQL 导入数据后，自增主键为什么冲突？

向表中导入带有明确 ID 的记录后，后续插入即使没有手动指定 ID，也可能遇到主键重复。排查时需要确认：冲突是不是发生在自增列上，以及该列关联的序列是否仍停留在导入前的位置。

表中的最大 ID 与序列是两份状态

PostgreSQL 的 serial 列通过关联序列生成默认值。显式插入一个 ID，并不等于调用序列取号，也不会自动把序列调整到这个 ID。

因此，表中已有的最大 ID 可能是 100，而序列下一次生成的值仍落在已有数据范围内。只有当这个值已经存在时，才会触发重复键冲突。导入数据并不一定导致问题，包含正确序列状态的恢复流程可能已经完成了同步。

下面沿用原笔记中的 staff 表作为例子，假设它位于 public schema，id 使用正向、步长为 1 的序列，表内已有记录。处理前先确认重复约束对应的确实是 id，并暂停相关写入和序列取号。

查询现有数据的最大 ID：

SELECT MAX(id) FROM public.staff;

不要仅根据命名惯例猜测序列名称。可以查询列实际关联的序列：

SELECT pg_get_serial_sequence('public.staff', 'id');

这个函数也支持 identity 列。如果返回 NULL，应先核对列的默认值及序列关联，而不是直接套用下面的重置语句。相关行为见 PostgreSQL 系统信息函数文档。

假设查到的序列是 public.staff_id_seq，可以查看它的状态：

SELECT last_value, is_called FROM public.staff_id_seq;

结合 MAX(id) 与 is_called 判断它是否落后；若序列已经领先，就不要为了对齐表中最大值而把它往回调。序列缓存及其他会话的取号也会影响排查，应在没有并发取号的维护场景中处理。

如果已经确认最大 ID 是 100，而且序列落后，可以让下一次取号从 101 开始：

ALTER SEQUENCE public.staff_id_seq RESTART WITH 101;

这里设置的是下一次取号返回的值。RESTART WITH 与只修改起始配置的 START WITH 含义不同。RESTART 是事务性的，并会阻塞同一序列上的并发取号，细节见 ALTER SEQUENCE 官方文档。

原笔记的另一种写法是用 setval：

SELECT setval(
  'public.staff_id_seq',
  (SELECT MAX(id) FROM public.staff),
  true
);

第三个参数 true 表示这个值已经被使用。对于步长为 1 的序列，如果设置为 100，下一次 nextval 会先前进，再返回 101。

省略第三个参数时，效果与 true 相同。因此下面是等价写法，不是另一种不同的修复方式：

SELECT setval('public.staff_id_seq', (SELECT MAX(id) FROM public.staff));

如果第三个参数为 false，下一次取号将直接返回传入的值。例如 setval('public.staff_id_seq', 101, false) 的下一次返回值也是 101。参数含义见序列函数官方文档。

这两种方法选择一种即可，不需要连续执行。

上面的 MAX(id) 写法针对非空表。空表的 MAX(id) 返回 NULL，应按序列实际起始值单独处理；不能未经检查就假定起始值总是 1。

查询最大值和重设序列不是一个能自动防止并发写入的流程。其他会话如果同时插入或继续使用提前缓存的编号，可能破坏所依据的状态。不要把这段 SQL 当作在活跃写入中随时可运行的通用脚本。

还要区分回滚行为：setval 对序列状态的修改会立即对其他事务可见，事务回滚不会撤销它；这与 ALTER SEQUENCE ... RESTART 不同。编号出现间隔本身则是正常现象，序列不保证连续无缺口。

完成调整后，应在测试环境通过一条省略 id 的正常插入，检查生成的 ID 是否避开已有记录，再验证应用原先失败的插入路径。本文没有执行这些操作，也没有把原笔记中的处理片段描述为已经验证的修复结果。