PostgreSQL插入冲突最直接的解决方式是使用ON CONFLICT子句，支持DO UPDATE更新现有记录或DO NOTHING忽略插入，适用于数据同步、幂等操作等场景。

PostgreSQL插入数据时遇到冲突，最直接且高效的处理方式就是利用其内置的

ON CONFLICT

子句。它允许我们在尝试插入新数据时，如果检测到与现有记录存在唯一性约束（比如主键或唯一索引）冲突，可以灵活选择是更新现有记录（即“upsert”操作），还是直接忽略这次插入，从而避免事务失败。这种机制极大地简化了并发写入和数据同步的逻辑。

解决方案

处理PostgreSQL插入冲突，核心在于

INSERT ... ON CONFLICT

语句。它提供了两种主要策略：

DO UPDATE

（更新）和

DO NOTHING

（忽略）。

1. 更新现有记录 (UPSERT):

ON CONFLICT ... DO UPDATE SET ...

当你希望在冲突发生时，用新数据更新已存在的记录，而不是插入新记录时，可以使用这种方式。这在很多场景下都非常有用，比如更新用户资料、统计计数器或同步数据。

INSERT INTO your_table (id, name, value, updated_at) VALUES (1, 'Alice', 100, NOW()) ON CONFLICT (id) DO UPDATE SET     name = EXCLUDED.name,     value = EXCLUDED.value,     updated_at = NOW();

这里需要注意几点：

• ON CONFLICT (id)

  : 指定冲突的目标，通常是主键或具有唯一约束的列。你也可以指定多个列，或者使用

  ON CONFLICT ON CONSTRAINT constraint_name

  来明确指定哪个唯一约束会触发冲突。

• EXCLUDED

  : 这是一个特殊的表别名，代表了“如果这次插入没有冲突，本应该插入的那一行数据”。通过

  EXCLUDED.column_name

  ，你可以引用尝试插入的新值来更新现有记录。

• SET ...

  : 定义了当冲突发生时，哪些列需要被更新。

2. 忽略冲突:

ON CONFLICT ... DO NOTHING

如果你只想插入那些不存在的新数据，而对于已经存在的重复数据，则选择默默地跳过，不进行任何操作，那么

DO NOTHING

是你的选择。这在批量数据导入、日志记录或确保操作幂等性时非常有用。

INSERT INTO your_table (id, name, value) VALUES (2, 'Bob', 200) ON CONFLICT (id) DO NOTHING;

当id为2的记录已经存在时，这条语句不会报错，也不会更新任何数据，只是什么也不做。

为什么会出现PostgreSQL插入冲突？理解背后的机制

说起来，数据库插入冲突，本质上是数据完整性约束在“工作”。在我们设计数据库表的时候，为了保证数据的唯一性和准确性，会定义一些约束，最常见的就是主键（Primary Key）和唯一约束（Unique Constraint）。

• 主键约束：这是最常见的冲突源。一张表只能有一个主键，并且主键列的值必须是唯一的，不能为NULL。如果你尝试插入一条记录，它的主键值与表中现有记录的主键值重复，那么就会发生冲突。
• 唯一约束：除了主键，我们也可以在其他列上定义唯一约束。比如，一个用户表可能有一个

  email

  列，我们希望每个用户的邮箱地址都是唯一的。当插入的

  email

  值与现有记录重复时，也会触发冲突。

• 并发操作：在多用户或高并发环境下，多个事务可能同时尝试插入或更新数据。即使在单个事务中，也可能因为其他事务的提交而导致冲突。比如，两个并发的进程都试图插入同一个

  id

  的记录，第一个成功了，第二个就会遇到冲突。

PostgreSQL在检测到这些约束被违反时，会抛出错误。

ON CONFLICT

子句正是为了优雅地处理这些预期中的冲突而设计的。它不是在错误发生后才去捕获和处理，而是在插入操作的原子性范围内，预先定义好冲突时的行为，这在性能和逻辑上都更优。

ON CONFLICT

子句的几种常用模式及适用场景

在我看来，

ON CONFLICT

的灵活度主要体现在对冲突目标的指定和对冲突行为的选择上。理解这些模式，能帮助我们更好地应对不同的业务场景。

1. 基于主键或唯一列的冲突处理

这是最常见的用法，也是前面示例中展示的。当你知道哪个列或哪些列组合会触发唯一性冲突时，直接在

ON CONFLICT

后面指定它们：

-- 针对单个唯一列（例如主键或唯一索引列） INSERT INTO products (sku, name, price) VALUES ('P001', 'Widget', 10.99) ON CONFLICT (sku) DO UPDATE SET name = EXCLUDED.name, price = EXCLUDED.price;  -- 针对复合唯一索引 -- 假设你有一个 (user_id, item_id) 的唯一索引 INSERT INTO user_items (user_id, item_id, quantity) VALUES (1, 101, 5) ON CONFLICT (user_id, item_id) DO UPDATE SET quantity = user_items.quantity + EXCLUDED.quantity;

这种模式适用于绝大多数需要处理重复数据的情况，比如数据同步、用户行为追踪（累加计数）等。

2. 基于约束名称的冲突处理

百度文心百中

百度大模型语义搜索体验中心

23

查看详情

有时候，你可能不想依赖列名，或者表上有多个唯一索引，你只想针对特定的那个索引进行冲突处理。这时，可以通过

ON CONFLICT ON CONSTRAINT constraint_name

来指定：

-- 假设你的products表在sku列上有一个名为'products_sku_key'的唯一约束 INSERT INTO products (sku, name, price) VALUES ('P002', 'Gadget', 25.00) ON CONFLICT ON CONSTRAINT products_sku_key DO UPDATE SET name = EXCLUDED.name, price = EXCLUDED.price;

这种方式的优点是更明确，特别是当表结构复杂，或者列名可能发生变化时，使用约束名会更稳定。它也适用于那些通过

CREATE UNIQUE INDEX

创建的，而不是直接在列定义时指定的唯一约束。

适用场景总结：

• DO UPDATE

  (UPSERT)：

  • 数据同步/ETL：从源系统导入数据到目标系统，确保目标系统数据是最新状态。
  • 用户配置/个人资料更新：用户修改个人信息时，确保数据被更新而不是创建重复记录。
  • 计数器/统计数据：例如，网站访问量、商品库存增减，确保每次操作都能正确累加或扣减。

• DO NOTHING

  (忽略)：

  • 日志记录/事件追踪：只关心新发生的事件，如果事件已经记录过，则忽略。
  • 批量数据导入：从外部文件导入大量数据时，只插入新记录，避免因重复数据而中断整个导入过程。
  • 幂等性操作：确保某个操作无论执行多少次，其结果都是一致的，不会产生副作用。

实践中如何选择合适的冲突处理策略？性能与数据一致性考量

选择正确的冲突处理策略，不仅仅是语法问题，更是对业务逻辑、数据完整性和系统性能的深思熟虑。

1. 业务逻辑优先

这是最核心的考量。你的业务希望在数据冲突时发生什么？

• 如果是“如果存在就更新，不存在就插入”，那毫无疑问是

  DO UPDATE

  。例如，电商平台的用户购物车，如果用户再次添加已有的商品，我们通常是增加数量，而不是添加一个重复的商品条目。

• 如果是“只关心新数据，重复的就当没看见”，那么

  DO NOTHING

  就非常合适。比如，一个系统收集用户行为日志，如果因为某种原因重复发送了同一条日志，我们通常希望只记录一次。

• 如果冲突代表了业务逻辑上的错误，比如试图创建一个不应该存在的重复订单号，那么可能根本不应该使用

  ON CONFLICT

  ，而是让它抛出错误，以便应用程序捕获并处理。

2. 性能考量

ON CONFLICT

通常比传统的“先SELECT再INSERT/UPDATE”模式更高效。

• 原子性：

  ON CONFLICT

  在数据库层面是原子操作，这意味着它在一个命令中完成，减少了网络往返（round trip）和潜在的竞态条件。

• 锁粒度：它在内部处理冲突时，通常能更有效地管理锁，避免了在

  SELECT

  和

  INSERT/UPDATE

  之间可能出现的死锁或长时间的锁等待。

• 索引利用：冲突检测直接利用了唯一索引，效率很高。

然而，这并不是说

ON CONFLICT

没有开销。如果

DO UPDATE

的

SET

子句包含复杂的计算或涉及其他表的查询，那么更新操作本身的开销会增加。在大规模并发写入下，即使是

ON CONFLICT

也可能导致锁等待，但相比手动处理通常会好很多。

3. 数据一致性与准确性

• DO NOTHING

  的“隐患”：虽然它能避免错误，但如果业务上期望的是更新，而你错误地使用了

  DO NOTHING

  ，就可能导致数据“陈旧”或不完整。例如，如果一个用户更新了他们的地址，但因为某种冲突被

  DO NOTHING

  了，那么数据库中的地址信息就不是最新的。

• DO UPDATE

  的“副作用”：确保

  DO UPDATE

  的逻辑是正确的。特别是涉及计数器或状态机的更新，要仔细考虑并发下的正确性。

  SET value = table.value + EXCLUDED.value

  这样的操作是安全的，因为

  ON CONFLICT

  保证了原子性。

4. 事务隔离级别

ON CONFLICT

操作是在当前事务的隔离级别下执行的。在大多数情况下，默认的

READ COMMITTED

或

REPEATABLE READ

隔离级别足以保证其正确性。它内部会处理好并发冲突的检测和解决，确保最终结果符合预期。

举例来说：

• 导入商品数据：你有一个CSV文件，里面有成千上万的商品信息，包括SKU、名称、价格。如果SKU是唯一的，你希望导入所有新商品，对于已存在的商品，则更新其名称和价格。那么，

  ON CONFLICT (sku) DO UPDATE SET name = EXCLUDED.name, price = EXCLUDED.price

  就是理想选择。

• 记录网站访客IP：你有一个表记录访问过的IP地址。你只关心有哪些IP访问过，不关心重复访问。那么，

  ON CONFLICT (ip_address) DO NOTHING

  能完美解决问题，既避免了重复记录，又节省了存储空间和处理时间。

• 用户积分累加：用户完成某个任务会获得积分。每次任务完成后，都尝试插入一条积分记录，如果用户已经有积分记录，则累加。那么，

  ON CONFLICT (user_id) DO UPDATE SET score = user_score.score + EXCLUDED.score

  会非常高效和安全。

最终，没有一劳永逸的解决方案。关键在于深入理解你的业务需求，并结合PostgreSQL提供的强大工具，选择最适合当前场景的策略。