必须用 SCOPE_IDENTITY()、LAST_INSERT_ID()、RETURNING 分别对应 SQL Server、MySQL、PostgreSQL；选错会导致获取他人插入的 ID，因三者作用域不同：SCOPE_IDENTITY() 限当前作用域，LAST_INSERT_ID() 限当前连接，RETURNING 与 INSERT 原子绑定。
SQL Server 用 SCOPE_IDENTITY()，MySQL 用 LAST_INSERT_ID()，PostgreSQL 用 RETURNING 子句——选错函数会拿到别人插入的 ID。
SQL Server：必须用 SCOPE_IDENTITY()，别碰 @@IDENTITY 和 IDENT_CURRENT()
这三个函数都返回自增 ID，但作用域完全不同：@@IDENTITY 会跨触发器捕获，IDENT_CURRENT('table') 是全局会话无关的，只有 SCOPE_IDENTITY() 严格限定在当前存储过程、当前作用域内。
常见错误是写完 INSERT 立刻用 SELECT @@IDENTITY，结果触发器里又插了一条日志，拿到的是日志表的 ID。
- 始终在
INSERT后**立即**调用SCOPE_IDENTITY()，中间不能有其他语句（包括PRINT或变量赋值） - 返回类型是
numeric(38,0)，如果要存进INT变量，记得显式转换：DECLARE @id INT = CAST(SCOPE_IDENTITY() AS INT) - 如果存储过程中有多个
INSERT，每次都要单独取，SCOPE_IDENTITY()不会“记住”上一次
MySQL：LAST_INSERT_ID() 是会话级的，但不依赖表名
LAST_INSERT_ID() 返回当前连接最后一次成功 INSERT 生成的自增 ID，它不关心表名，也不受触发器干扰——前提是触发器没执行新的 INSERT ... VALUES（带显式值的插入不会改变该值）。
容易踩的坑是多线程共用连接池时误以为它线程安全；其实它是**连接级**而非线程级，只要连接没被复用就安全。
- 不需要参数，直接写
SELECT LAST_INSERT_ID()或在存储过程中赋值：SET @id = LAST_INSERT_ID() - 如果
INSERT语句用了INSERT ... SELECT或批量插入，它只返回**第一条插入记录**的 ID - 手动设置过
LAST_INSERT_ID(123)后，后续INSERT会从 124 开始自增（除非表定义了AUTO_INCREMENT值），这会影响后续读取
PostgreSQL：用 RETURNING 比 currval() 更可靠
PostgreSQL 没有全局“最后插入 ID”的概念。currval('seq_name') 看似方便，但它依赖序列名，且要求当前会话**已调用过 nextval()** ——如果插入时用了默认值或 DEFAULT，可能没显式调用，currval() 就报错。
RETURNING 是真正与 INSERT 绑定的，它在插入同时返回指定列，天然避免竞态。
- 写法：
INSERT INTO users (name) VALUES ('alice') RETURNING id; - 在存储过程（PL/pgSQL）中，可用
RETURNING id INTO my_id直接赋值给变量 - 支持返回多列甚至表达式：
RETURNING id, created_at, 'inserted'::text AS status - 如果表没有显式定义序列（比如用
GENERATED ALWAYS AS IDENTITY），RETURNING仍是唯一稳妥方式
跨数据库移植时最麻烦的不是语法，而是对“最后插入 ID”这个概念的理解偏差——它从来不是数据库全局状态，而是跟插入动作、会话、作用域死死绑在一起的。漏掉作用域限制，或者在多语句之间加了无关操作，ID 就悄悄变了。
