Oracle Sequence脱节是主键冲突主因，即NEXTVAL返回值已存在于表中；重置需三步：查表最大ID、临时调大increment by并执行NEXTVAL、恢复increment by 1。
Oracle Sequence 脱节是主键冲突的真正元凶
你在 C# 里调用 INSERT INTO t (id, name) VALUES (my_seq.NEXTVAL, 'xxx') 报 ORA-00001: unique constraint violated，大概率不是代码写错了，而是 my_seq 当前 NEXTVAL 返回的值，已经在表里存在了。Sequence 本身不查表、不校验、不回滚——它只管递增。所以开发环境反复清库、测试脚本中途失败、手动插入过测试数据，都可能让 Sequence 值和表中最大 ID 脱节。
重置 Sequence 必须分三步走，少一步就失效
不能直接 ALTER SEQUENCE my_seq RESTART WITH 124（Oracle 12c+ 才支持），老版本（如 11g）必须靠“改步长→取一次→改回步长”三连操作。关键点：
-
SELECT NVL(MAX(id), 0) FROM your_table先拿到当前最大 ID（比如是123） -
ALTER SEQUENCE my_seq INCREMENT BY 124 - 123 - 1→ 步长设为0？不对，是0会导致下一次NEXTVAL还是123；正确是设为124 - 123 = 1，再减 1 得0？等等——实际要设成124 - 123 - 1 = 0，但 Oracle 不允许步长为 0，所以得设成124 - 123 = 1，然后SELECT my_seq.NEXTVAL FROM DUAL就返回124；更稳妥写法是：ALTER SEQUENCE my_seq INCREMENT BY (124 - 123)，再执行SELECT my_seq.NEXTVAL FROM DUAL，最后ALTER SEQUENCE my_seq INCREMENT BY 1 - 第二步的
SELECT ... FROM DUAL必须执行，否则 Sequence 不推进；第三步不改回INCREMENT BY 1，后续所有插入都会错乱
批量插入时别在循环里调 NEXTVAL
C# 中常见反模式：for each row { cmd.CommandText = "INSERT INTO t VALUES (seq.NEXTVAL, ...)"; cmd.ExecuteNonQuery(); }。这不仅性能差，还放大 Sequence 脱节风险——每条语句都独立触发一次 NEXTVAL，一旦某条失败，Sequence 已跳号，空档永远无法填补。正确做法：
- 用 Oracle 的
FORALL+ PL/SQL 关联数组（需先定义 UDT 类型），在数据库端一次性生成 ID 序列 - 或在 C# 端用
SELECT seq.NEXTVAL FROM DUAL CONNECT BY LEVEL 预取一批 ID，再批量绑定插入 - 若用 ODP.NET 的
OracleBulkCopy，它不支持自动 ID 生成，必须提前准备好 ID 列值（此时 Sequence 重置就更关键）
MERGE 比 INSERT 更适合有冲突风险的场景
当业务允许“有则更新、无则插入”时，硬上 INSERT 就是给自己埋雷。C# 调用 Oracle 存储过程或直接执行 MERGE 是更稳的选择：
MERGE INTO target_table t USING (SELECT :id AS id, :name AS name FROM DUAL) s ON (t.id = s.id) WHEN MATCHED THEN UPDATE SET t.name = s.name WHEN NOT MATCHED THEN INSERT (id, name) VALUES (s.id, s.name);
注意：MERGE 的 ON 条件必须走索引（最好是主键或唯一索引），否则全表扫描会拖垮性能；且不能在 USING 子句里直接用序列函数（如 seq.NEXTVAL），需提前算好 ID 再传入。
最易被忽略的一点：Sequence 重置操作本身不是事务安全的，它不参与 rollback。所以一定要在应用层确认重置成功后再启动批量任务，而不是把它塞进同一个事务里指望自动回滚——那只会让你更难排查为什么插入又失败了。
