如何用 RETURNING / OUTPUT 返回插入/更新后的自增 ID_技术教程

PostgreSQL 用 RETURNING 最直接获取刚插入的自增 ID，需列名与表定义完全一致；SQL Server 用 OUTPUT 需 INSERTED. 前缀且须显式接收；MySQL 依赖 LAST_INSERT_ID()，受会话和连接约束；ORM 封装差异但行为边界不同。

PostgreSQL 的 RETURNING 是最直接的方式，它在执行 INSERT 时同步返回指定列（包括序列生成的 ID）。不需要额外查询，也不依赖事务隔离级别。

常见错误是写成 INSERT ... RETURNING id; 却忘了表里主键列实际叫 user_id 或 record_id —— 必须和表定义完全一致。

INSERT INTO users (name, email) VALUES ('Alice', 'a@example.com') RETURNING id;（假设主键是 id）
支持返回多列：RETURNING id, created_at, updated_at
如果用 serial 或 GENERATED ALWAYS AS IDENTITY，RETURNING 能拿到最终值，哪怕触发器改过它
不能在普通函数里用 RETURNING 直接赋值给变量，得配合 WITH 或 PL/pgSQL 的 RETURNING INTO

OUTPUT 是 SQL Server 的等效机制，但它不返回结果集给客户端，而是把数据“输出”到临时结构中。最常踩的坑是：在存储过程中用了 OUTPUT 却没接住结果，或者误以为它像 PostgreSQL 那样自动返回。

基础用法：INSERT INTO users (name, email) OUTPUT INSERTED.id VALUES ('Bob', 'b@example.com');
必须用 INSERTED. 前缀，更新时还可用 DELETED.；不能省略
如果在存储过程中使用，想把 ID 返回给调用方，得用 OUTPUT INTO @table_var 再 SELECT 出来，否则客户端收不到
OUTPUT 在语句级生效，不受事务回滚影响 —— 即使后面 ROLLBACK，OUTPUT 已经吐出的 ID 仍有效（这点和 PostgreSQL 不同）

MySQL 5.7 和 8.0 都不支持 RETURNING 或 OUTPUT，只能用 LAST_INSERT_ID()。它不是函数调用意义上的“返回”，而是会话级状态值，依赖上一条 INSERT 是否触发了自增列。

必须紧接在 INSERT 后执行：INSERT INTO users (name) VALUES ('Charlie'); SELECT LAST_INSERT_ID();
如果 INSERT 没写自增列（比如显式指定了 id=100），LAST_INSERT_ID() 不更新 —— 这点容易被忽略
批量插入时，只返回第一条生成的 ID，不是全部；要拿全部 ID 得用临时表或应用层拆解
在连接池环境下，必须确保两次语句走的是同一个物理连接，否则可能拿到别人插入的 ID

ORM 封装了底层差异，但默认行为不一定符合直觉。比如 SQLAlchemy 的 session.add() 不立刻执行，ID 是在 flush() 或 commit() 时才真正生成并填充到对象上。

SQLAlchemy：用 session.flush() 触发 INSERT 并填充 obj.id，不用等 commit()；但若事务回滚，这个 ID 就作废了（自增不可逆）
Django ORM：Model.objects.create() 立即返回带 ID 的实例，内部已处理好；但 bulk_create() 不设 ID，得手动查
MyBatis（Java）：配置 useGeneratedKeys="true" + keyProperty 才能映射回对象，否则字段为空
所有 ORM 都不保证跨数据库兼容 —— 比如在 PostgreSQL 用 RETURNING，切到 MySQL 就退化为 LAST_INSERT_ID()，逻辑没变但行为边
界不同

真正麻烦的不是语法本身，而是当插入失败重试、批量操作、或用到了延迟加载/连接复用时，ID 的可见性、唯一性和时效性会突然变得模糊。别只盯着“怎么拿到”，先想清楚“什么时候需要它”和“它是否还有效”。

17370845950