应使用 setval() 显式设置序列值为表中最大 ID（如 SELECT setval('seq', (SELECT COALESCE(MAX(id), 0) FROM tbl), true)），确保下一次 nextval() 返回最大 ID 加一；不可依赖 ALTER SEQUENCE RESTART，因其重置起始点而非当前值，且不感知表数据状态。
如何用 setval() 修复序列与表数据脱节
直接调用 setval() 是最常用、最可控的同步方式，它绕过所有隐式逻辑，强制把序列当前值设为你指定的数字。但关键在于：你设的这个数，必须是「下一次 nextval() 应该返回的值」，而不是表里最大的 ID。
- 如果表中最大
id是 100，你想让下一条记录用 101，就该执行SELECT setval('my_table_id_seq', 100)（不是 101） - 空表时务必用
COALESCE(MAX(id), 0)，否则MAX(id)返回NULL会导致setval()报错 - 序列名若含 schema，必须写全，比如
'public.users_id_seq'；漏掉public.在非默认 schema 下会失败 -
setval()默认不校验新值是否合法（比如是否超过max_value），需提前确认，否则后续插入可能直接报错
为什么不能只用 ALTER SEQUENCE RESTART
ALTER SEQUENCE ... RESTART WITH N 看似更直观，但它有个致命陷阱：它重置的是序列的「起始点」，而非「当前值」。当序列已存在且被用过，RESTART 实际效果取决于序列的 is_called 状态——如果上次 nextval() 后事务回滚了，is_called 可能为 false，此时 RESTART WITH 100 会让下一次 nextval() 直接返回 100，而非 101，导致主键冲突。
-
RESTART适合全新序列或明确知道状态的场景，不适合修复已脱节的生产序列 - 它无法动态获取表中
MAX(id)，必须手动拼接 SQL，易出错 - 在迁移脚本中混用
RESTART和setval()容易造成行为不一致，建议统一用setval()
如何安全获取目标序列名而不硬编码
硬写 'users_id_seq' 这类名字在重构或跨环境部署时极易失效。PostgreSQL 提供了 pg_get_serial_sequence() 函数，能根据表名和列名自动查出当前绑定的序列。
- 用法示例：
SELECT pg_get_serial_sequence('public.users', 'id')，返回'public.users_id_seq'或NULL（未绑定时） - 必须确保目标列确实有默认值来自序列，否则返回
NULL，需配合COALESCE做兜底 - 在自动化脚本中，应先检查返回值是否为空，避免对
NULL调用setval() - 该函数不解析
GENERATED BY DEFAULT AS IDENTITY列，只适用于传统SERIAL或显式nextval()默认值
setval() 的第三个参数 is_called 怎么设
setval(seq, newval, is_called) 的第三个布尔参数决定序列内部计数器如何解释 newval。这是最容易被忽略的细节。
- 设为
true（默认）：表示newval是「上一次已返回的值」，下次nextval()将返回newval + increment_by - 设为
false：表示newval是「下一次要返回的值」，下次nextval()就直接返回它 - 绝大多数同步场景应显式传
true，并把newval设为表中最大id（即SELECT setval(..., (SELECT MAX(id) FROM t), true)） - 传
false风险高：若误设，可能导致跳号或重复；仅在极少数需要精确控制首次返回值时使用
真正麻烦的不是调用 setval() 这一行 SQL，而是确认「该设成多少」以及「设给谁」——序列名可能因 schema、命名规则、IDENTITY 切换而变化，表中最大 ID 可能为 NULL 或超出整型范围，这些边界条件一旦漏掉，修复就变成了新的故障源。
