PostgreSQL 用 RETURNING 最直接获取刚插入的自增 ID，需列名与表定义完全一致；SQL Server 用 OUTPUT 需 INSERTED. 前缀且须显式接收；MySQL 依赖 LAST_INSERT_ID()，受会话和连接约束；ORM 封装差异但行为边界不同。
PostgreSQL 用 RETURNING 拿刚插入的自增 ID
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
SQL Server 用 OUTPUT 捕获新 ID，但要注意作用域
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 没有原生 RETURNING，得靠 LAST_INSERT_ID() 补位
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、Django ORM）怎么安全取 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 的可见性、唯一性和时效性会突然变得模糊。别只盯着“怎么拿到”，先想清楚“什么时候需要它”和“它是否还有效”。
