重置序列前必须先查表中最大ID并确认序列名，再用SETVAL('seq_name', N, true)安全设置；TRUNCATE应优先用RESTART IDENTITY；批量修复需动态生成SQL并人工核验。
重置序列前必须确认序列名和当前最大ID
直接执行 SETVAL 却不核对目标值，是主键冲突的头号原因。PostgreSQL 不会自动同步序列值和表中实际最大ID，尤其在批量导入、TRUNCATE未带 RESTART IDENTITY 或手动插入过ID后，极易脱节。
先查真实最大ID：
SELECT COALESCE(MAX(id), 0) FROM users;
再确认序列名（别凭印象写 users_id_seq）：
SELECT schemaname, sequencename FROM pg_sequences WHERE tablename = 'users' AND schemaname = 'public';
- 如果表在非
publicschema，必须带前缀，比如'myapp.users_id_seq'，否则报错relation "users_id_seq" does not exist -
pg_sequences默认只查当前 search_path 下的 schema，跨 schema 必须显式加schemaname = 'xxx'过滤 - 用
\d users在 psql 中也能看到关联的序列名，但无法脚本化，不适合批量操作
用 SETVAL 安全设置新起点，第三个参数不能为 false
SETVAL('seq_name', N, true) 是生产环境唯一推荐用法。设为 true 表示“这个值已被使用”，下一次 NEXTVAL 返回的是 N + 1；设 false 会导致下一条 INSERT 直接用 N，若表里已有该ID，立刻主键冲突。
例如：表中最大ID是 58231，你想让下一条记录从 58232 开始：
SELECT SETVAL('public.users_id_seq', 58231, true);
- 不要写
SETVAL('users_id_seq', 58231, false)—— 这等于主动埋雷 - 序列名必须是
regclass类型，字符串需加单引号；含大小写或特殊字符时，要用双引号嵌套，如'"User_ID_Seq"' - 执行后可立即验证：
SELECT NEXTVAL('public.users_id_seq');应返回 58232
TRUNCATE 表后想重置序列？优先用 RESTART IDENTITY
如果只是清空整张表并从 1 重新开始，TRUNCATE ... RESTART IDENTITY 比手写 SETVAL 更安全、更原子：
TRUNCATE TABLE users RESTART IDENTITY;
- 它会自动定位并重置所有被该表列
OWNED BY的序列，无需你手动找序列名 - 不带
RESTART IDENTITY的TRUNCATE只删数据，序列值原封不动，这是常见疏漏点 - 仅适用于整表清空场景；若只删部分数据（如
DELETE WHERE ...），必须走SETVAL路线
批量修复多个表的序列？用 pg_sequences 动态生成 SQL
当有几十张表需要统一修复时，逐条写 SETVAL 不现实。核心思路是：从元数据查出所有需处理的序列 → 计算每张表当前最大ID → 拼出带 SETVAL 的语句。
一个最小可行脚本（需在 psql 中运行）：
SELECT format('SELECT SETVAL(%L, GREATEST(0, (SELECT COALESCE(MAX(id), 0) FROM %I.%I)), true);',
schemaname || '.' || sequencename,
schemaname,
tablename)
FROM pg_sequences
WHERE schemaname = 'public' AND tablename IN ('users', 'orders', 'products');
- 输出的是可复制执行的 SQL 字符串，不是直接执行结果；务必人工检查生成的语句是否合理
-
GREATEST(0, ...)防止空表时MAX(id)为 NULL 导致语法错误 - 切勿对没有对应表列的孤立序列（orphaned sequence）执行此逻辑，可能破坏其他表的自增逻辑
序列所有权和当前值脱节的问题，往往在数据量增长到临界点才暴露——修复动作本身很快，但漏掉一张表、写错一个 schema 前缀，就可能让下一次上线插入直接失败。
