PostgreSQL中推荐使用RETURNING子句在INSERT后直接获取主键，因其确保原子性、避免竞态条件，并减少数据库往返。该方法适用于SERIAL、UUID等主键类型，且可与ON CONFLICT结合实现UPSERT并返回更新后的记录信息，提升效率与代码简洁性。
在PostgreSQL中，如果你想在执行
INSERT
语句后立即获取新生成的主键（通常是自增ID），最直接且推荐的方法是使用
RETURNING id
子句。这允许你在同一个数据库请求中完成数据插入和ID的检索，非常高效和安全。
在PostgreSQL中，当你需要在一个
INSERT
操作完成后立即获取新生成的主键（通常是序列生成的ID）时，最优雅且推荐的做法是利用
RETURNING
子句。这不仅仅是一种语法糖，它确保了原子性——你的插入和获取ID是同一个事务操作的一部分，避免了潜在的竞态条件或数据不一致问题。
想象一下，你有一个
users
表，其中
id
是
SERIAL
类型的主键：
CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE);
当你插入一条新用户记录时，你只需要在
INSERT
语句的末尾加上
RETURNING id
：
INSERT INTO users (username, email) VALUES ('alice', 'alice@example.com') RETURNING id;
执行这条语句后，PostgreSQL会直接返回一个结果集，其中包含新插入记录的
id
值。如果你的插入语句是批量操作，例如：
INSERT INTO users (username, email) VALUES('bob', 'bob@example.com'),('charlie', 'charlie@example.com')RETURNING id, username;
它会返回一个包含两行记录的结果集，每行包含对应的
id
和
username
。这种方式不仅限于
id
，你可以返回任何你需要的列。它的强大之处在于，它将数据插入和结果检索合并成了一个单一的数据库往返（round trip），这对于性能和代码简洁性都非常有益。
为什么推荐使用
RETURNING
子句？它解决了哪些常见痛点？
我个人觉得，
RETURNING
子句在PostgreSQL里真的是一个非常“聪明”的设计。它不仅仅是提供了便利，更重要的是，它从根本上解决了几个在其他数据库系统里可能需要复杂逻辑才能应对的痛点。
最核心的一点是原子性。在没有
RETURNING
的情况下，如果你想获取新插入的ID，你可能需要先
INSERT
，然后紧接着执行一个
SELECT
语句，比如
SELECT id FROM users WHERE username = 'alice' AND email = 'alice@example.com'
。这种“先插后查”的模式，在并发量大的系统里，极易出现问题。想象一下，在你
INSERT
和
SELECT
之间，可能有另一个事务插入了完全相同的
username
和
（如果这些字段没有唯一约束），或者你查询的条件不够唯一，导致你拿到了错误的ID。
RETURNING
则将这两个操作绑定在一起，确保了你拿到的ID就是你刚刚插入的那条记录的ID，没有中间环节，没有竞态条件。
其次，它极大地简化了应用层的代码逻辑。开发者不需要编写额外的查询语句，也不需要担心如何精确地匹配到刚刚插入的那条记录。一个简单的
INSERT ... RETURNING id
就能搞定，这让代码变得更简洁、更易读、更不容易出错。
最后，是性能上的优势。将
INSERT
和
SELECT
合并为一个数据库往返（round trip），意味着客户端和数据库服务器之间的通信开销减少了一半。在网络延迟较高或者需要频繁插入数据的场景下，这种优化是显而易见的。它避免了不必要的网络I/O和数据库资源消耗，使得整个操作更加高效。
如果主键不是
SERIAL
类型，
RETURNING
还能用吗？
当然可以！
RETURNING
子句的强大之处在于它不绑定于任何特定的数据类型或主键生成策略。无论你的主键是
SERIAL
、
BIGSERIAL
、
UUID
、或者是通过触发器（trigger）生成的，甚至是用户手动指定的值，只要它是你
INSERT
操作后数据表里真实存在的列，你都可以通过
RETURNING
来获取。
举个例子，如果你的主键是一个
UUID
类型，并且你是在应用层生成UUID然后插入的：
arXiv Xplorer
ArXiv 语义搜索引擎，帮您快速轻松的查找，保存和下载arXiv文章。
73 查看详情 
CREATE TABLE products ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- 或者在应用层生成 name VARCHAR(100) NOT NULL, price NUMERIC(10, 2));
假设你让数据库自动生成UUID：
INSERT INTO products (name, price) VALUES ('Laptop', 1200.00) RETURNING id;
或者，如果你在应用层生成了UUID：
-- 假设应用层生成了 'a1b2c3d4-e5f6-7890-1234-567890abcdef'INSERT INTO products (id, name, price) VALUES ('a1b2c3d4-e5f6-7890-1234-567890abcdef', 'Monitor', 300.00) RETURNING id;
在这两种情况下，
RETURNING id
都会准确地返回那条新记录的
UUID
主键。
甚至，你不仅仅可以返回主键，任何你认为在
INSERT
后需要立即知道的列，都可以被
RETURNING
。比如，你可能想知道一个订单创建后，它的
order_id
和
created_at
时间戳：
CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_id INT NOT NULL, order_date TIMESTAMP DEFAULT NOW());INSERT INTO orders (customer_id) VALUES (101) RETURNING order_id, order_date;
这会返回新订单的ID和数据库自动生成的创建时间。这种灵活性使得
RETURNING
成为了PostgreSQL里处理插入操作后数据检索的“瑞士军刀”。
结合
ON CONFLICT
子句，
RETURNING
如何在 UPSERT 场景下发挥作用？
这里要提到一个PostgreSQL的杀手级特性——
INSERT ... ON CONFLICT
，也就是我们常说的UPSERT（更新或插入）。当这个特性与
RETURNING
结合时，它的实用性简直是指数级增长。
想象一个场景：你需要插入一条记录，但如果这条记录（根据某个唯一约束）已经存在，你就想更新它，并且无论最终是插入还是更新，你都希望获取到最终那条记录的ID和一些其他信息。这就是
INSERT ... ON CONFLICT ... DO UPDATE ... RETURNING
的用武之地。
我们继续用
users
表的例子，假设
字段是唯一的：
CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE);
现在，我们想插入一个用户，如果
冲突了，就更新
username
：
-- 第一次插入，'john@example.com' 不存在INSERT INTO users (username, email) VALUES ('John Doe', 'john@example.com')ON CONFLICT (email) DO UPDATE SET username = EXCLUDED.usernameRETURNING id, username, email;-- 假设返回 id=1, username='John Doe', email='john@example.com'-- 第二次插入，'john@example.com' 已经存在，会触发更新INSERT INTO users (username, email) VALUES ('Johnny Bravo', 'john@example.com')ON CONFLICT (email) DO UPDATE SET username = EXCLUDED.usernameRETURNING id, username, email;
在第二次执行时，由于
冲突，
ON CONFLICT
子句会被激活，
username
会被更新为
Johnny Bravo
。此时，
RETURNING
子句会返回最终状态的记录信息。也就是说，它会返回
id=1
（因为是更新了原有记录），
username='Johnny Bravo'
和
email='john@example.com'
。
这个机制非常强大，它让你的应用程序可以以一种统一的方式处理“插入或更新并获取结果”的逻辑，无论是新增还是修改，你都能拿到最新、最准确的数据状态。这大大简化了业务逻辑层面的判断和处理，避免了多次查询和复杂的事务控制，让代码更健壮、更高效。在我看来，这是PostgreSQL在处理数据同步和数据一致性方面的一个非常优雅的解决方案。
以上就是PostgreSQL插入返回ID怎么实现_PostgreSQL插入返回主键方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1089394.html
微信扫一扫 
支付宝扫一扫 
