PostgreSQL主键冲突源于序列未同步至表最大ID，Navicat“重置序列”仅对空表生效；须手动执行SELECT setval('seq', (SELECT COALESCE(MAX(id),0) FROM table))修复。
同步后插入报“duplicate key violates unique constraint”
这不是数据重复，而是 PostgreSQL 的序列（如 users_id_seq）没被更新到目标表当前最大 ID 值。Navicat 默认不触碰序列值，哪怕你勾选了“重置序列”，也只对空表生效；若目标表已有数据，它不会自动执行 SELECT setval('xxx', (SELECT MAX(id) FROM xxx))。
常见表现：同步完立刻 INSERT，ID 从 1 开始撞主键；或者同步中途卡在 95%，日志里没报错但后续写入失败。
- 手动补设序列值：在目标库执行
SELECT setval('table_id_seq', (SELECT COALESCE(MAX(id), 0) FROM table))（COALESCE防空表报错） - 若用 Navicat 批处理定时运行，必须把这句 SQL 写进「同步后执行」的 Initial statement 或单独建个查询任务
- 别依赖“重置序列”勾选项——它只在目标表为空时才真正起作用
Navicat 同步脚本里压根没生成 setval 语句
Navicat 的结构同步（Structure Synchronization）和数据同步（Data Synchronization）是两套逻辑。前者只管 DDL，后者只管 DML，两者都不自动生成 setval。即使你看到“同步完成”，只要目标表非空，序列就大概率脱节。
- 检查同步预览脚本：点“下一步”后务必点“查看脚本”，搜索
setval—— 几乎肯定没有 - 不能靠“创建前删除目标对象”来绕过：这会删掉序列本身，重建后仍是默认起始值 1
- 正确做法是把
setval当作同步流程的最后一个步骤，和 INSERT 同批提交，避免中间有其他写入干扰
多个序列关联同一字段导致“more than one owned sequence”
迁移或多次同步后，PostgreSQL 系统表 pg_depend 可能记录了多个序列都“owned by”同一个字段，比如 id 字段同时依赖 users_id_seq_1 和 users_id_seq_2。此时哪怕序列值本身正确，INSERT 也会直接报错。
- 查冲突：执行
SELECT objid::regclass, refobjid::regclass FROM pg_depend WHERE classid = 'pg_class'::regclass AND refclassid = 'pg_class'::regclass AND deptype = 'a' AND objid = 'users_id'::regclass - 清理冗余依赖：用
ALTER SEQUENCE seq_name OWNED BY NONE先解除无关序列的绑定 - 只保留一个序列：确认哪个是主序列，再用
ALTER SEQUENCE seq_name OWNED BY users.id显式绑定
“重置序列”选项为什么有时失效
这个选项实际只影响 Navicat 是否在同步脚本中插入 ALTER SEQUENCE ... RESTART WITH N。但它不会读取目标表真实数据，N 是硬编码的（通常是 1 或源表当前值），而源表当前值又可能因未提交事务、MVCC 快照偏差而不准。
- 它不等价于
setval：前者是“下次从 N 开始”，后者是“下次从 N+1 开始”，语义不同 - 跨版本同步更危险：PostgreSQL 12+ 的 IDENTITY 列底层机制和 SERIAL 不同，Navicat 16.2 对前者的序列处理逻辑尚未对齐
- 最稳方案：关掉这个选项，改用独立的
setval脚本，且在同步完成后、应用上线前手动跑一次
