postgresql中用returning获取插入后自增id最直接可靠；它原子性返回新行字段（如id、created_at），支持批量插入、on conflict及with子句，避免竞态与额外查询。
PostgreSQL 中用 RETURNING 拿插入后的自增 ID 最直接
PostgreSQL 原生支持 RETURNING，插入后立刻拿到刚生成的主键值，不用额外查一次。这是最干净、最原子的做法。
常见错误是写成 INSERT ... VALUES (...) RETURNING id; 却忘了表里 id 确实是自增（SERIAL 或 GENERATED ALWAYS AS IDENTITY），或者字段名拼错导致返回 NULL。
实操建议：
- 确保目标列是主键且有默认自增逻辑，比如定义为
id SERIAL PRIMARY KEY -
RETURNING后可跟任意表达式，不只是单个字段，例如RETURNING id, created_at, LOWER(name) - 如果用在函数或 CTE 里，注意
RETURNING的结果能被上层直接引用，不需临时表 - 批量插入时，
RETURNING会返回所有新行的结果集，不是只返回一行
INSERT INTO users (name, email)
VALUES ('Alice', 'a@example.com')
RETURNING id;
MySQL 不支持 RETURNING，得靠 LAST_INSERT_ID()
MySQL 5.7 和 8.0 都没有 RETURNING 子句。强行写会报错：ERROR 1064 (42000): You have an error in your SQL syntax。
替代方案是插入后立即调用 LAST_INSERT_ID()，但它有前提：必须是同一个连接、且中间没执行其他含自增插入的语句。
实操建议：
- 不要在插入和查
LAST_INSERT_ID()之间执行其他INSERT、REPLACE或LOAD DATA - 在事务中使用是安全的，但跨连接无效 —— 别在另一个线程/连接里去查
- 如果用了
INSERT ... ON DUPLICATE KEY UPDATE，LAST_INSERT_ID()行为可能不符合预期（取决于是否触发插入） - 想返回多列？不行。
LAST_INSERT_ID()只返回 ID；要其他字段，只能再查一次SELECT ... WHERE id = LAST_INSERT_ID()
SQLite 的 RETURNING 是 3.35.0+ 才有的新特性
SQLite 从 3.35.0（2021 年 3 月发布）开始支持 RETURNING，但很多系统自带的 SQLite 版本仍低于此（比如 CentOS 7 默认是 3.7.17）。直接用会报错：near "RETURNING": syntax error。
实操建议：
- 先确认版本：
SELECT sqlite_version();，低于 3.35.0 就别硬上RETURNING - 支持语法和 PostgreSQL 基本一致，但不支持
RETURNING *，必须显式列出字段 - 若版本不够，退回到
INSERT后查last_insert_rowid()，它线程安全、连接内有效 - 注意：Python 的
sqlite3模块默认绑定系统 SQLite，升级 Python 不等于升级 SQLite 引擎
INSERT INTO logs (msg, level)
VALUES ('startup', 'INFO')
RETURNING rowid, msg;
SQL Server 和 Oracle 怎么办？根本没 RETURNING
SQL Server 用 OUTPUT 子句，Oracle 用 RETURNING INTO，两者语法和语义都和标准 RETURNING 不兼容，也不能跨数据库移植。
实操建议：
- SQL Server：
OUTPUT INSERTED.id必须紧跟在INSERT后，不能加分号隔开；支持INSERTED.*，但不推荐（隐式依赖列序） - Oracle：
RETURNING id INTO :id_var要求用绑定变量，纯 SQL 工具（如 DBeaver 直连）可能不自动处理，容易卡在“未定义变量”错误 - ORM 用户注意：Django 的
.save()、SQLAlchemy 的session.flush()底层已适配各数据库的这类机制，优先走 ORM 封装比手写 SQL 更稳 - 别试图用
SELECT @@IDENTITY（SQL Server）或SELECT SEQ.CURRVAL（Oracle）替代 —— 它们要么不安全，要么要求先NEXTVAL
RETURNING 不是银弹。真正容易被忽略的是连接生命周期和并发上下文 —— 同一个连接里看似安全的操作，在连接池场景下可能被复用或错位，这时候 ORM 的封装反而比裸 SQL 更可靠。
