sql server用scope_identity()、mysql用last_insert_id()、postgresql用returning子句获取刚插入的自增id，三者作用域机制不同，不可跨库通用，需按数据库类型选择对应方案。
SQL Server 中用 SCOPE_IDENTITY() 获取刚插入的自增 ID
在 SQL Server 存储过程中，SCOPE_IDENTITY() 是最安全、最常用的方式。它只返回当前作用域（比如当前存储过程、当前批处理）内最后一条 INSERT 生成的自增 ID，不会受触发器或并行操作干扰。
常见错误是误用 @@IDENTITY —— 它会跨作用域返回，如果表上有触发器又往另一张自增表里插了数据，@@IDENTITY 就会返回触发器里的 ID，而不是你想要的那条。
-
SCOPE_IDENTITY()必须紧跟在INSERT语句之后执行，中间不能有其他影响标识列的操作（如另一个INSERT） - 不能在
INSERT ... SELECT多行插入后直接用——它只返回第一条插入的 ID；多行场景需改用OUTPUT子句 - 返回值类型和自增列一致（如
INT或BIGINT），建议显式转换或声明对应类型的变量接收
MySQL 中用 LAST_INSERT_ID() 获取刚插入的自增 ID
MySQL 没有作用域概念，LAST_INSERT_ID() 是连接级的，只要没被其他 INSERT / REPLACE / UPDATE 覆盖，就能拿到本连接最近一次插入的自增 ID。
关键点在于：它不依赖当前语句是否成功，而是依赖“最近一次修改自增列的操作”。如果 INSERT 因主键冲突失败，LAST_INSERT_ID() 不变；但如果用了 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，行为会不同。
-
LAST_INSERT_ID()在存储过程中可直接赋值给变量：SET @new_id = LAST_INSERT_ID(); - 批量插入（
INSERT ... VALUES (...), (...)）时，它返回的是第一个生成的 ID，不是最大 ID - 如果手动指定自增列值（如
INSERT INTO t(id, name) VALUES (100, 'x')），LAST_INSERT_ID()仍返回该手动值，而非下一个自动生成值
PostgreSQL 中用 RETURNING 子句直接取 ID
PostgreSQL 不提供类似 SCOPE_IDENTITY() 的函数，推荐用 INSERT ... RETURNING id 语法，既原子又明确。它在插入的同时返回指定列，避免额外查询或竞态风险。
这个方案比先 INSERT 再 SELECT LASTVAL() 更可靠，尤其在高并发下——LASTVAL() 返回的是当前会话最后一次序列使用值，但如果你的插入没用序列（比如用 DEFAULT 以外的方式赋值），它就不可靠。
-
RETURNING可返回多个字段：INSERT INTO users(name) VALUES ('alice') RETURNING id, created_at; - 在存储过程（
FUNCTION或PROCEDURE）中，可用RETURNING配合INTO把值存入变量 - 不支持在普通 SQL 批处理中跨语句使用；必须和
INSERT写在同一语句里
跨数据库兼容性差，别硬套同一套逻辑
没有一种写法能在 SQL Server、MySQL、PostgreSQL 里通用。试图封装成统一函数或宏，反而容易埋坑——比如把 PostgreSQL 的 RETURNING 当成 MySQL 的 LAST_INSERT_ID() 用，结果语法报错或逻辑错乱。
实际项目中，要么按目标数据库选对应方案，要么在 ORM 层（如 Entity Framework、MyBatis、SQLAlchemy）里利用其内置的 ID 获取机制，由框架屏蔽差异。手写存储过程时，务必确认当前数据库类型再选函数。
最容易被忽略的是：有些开发会用 SELECT MAX(id) 来“估算”刚插入的 ID，这在并发下完全不可靠，哪怕加了事务也不行——除非加表锁，但性能代价太大，纯属倒退。
