MySQL INSERT ... RETURNING 怎样读取写入后的行

如果你把 PostgreSQL、SQLite 或其他数据库里的习惯带到 MySQL，可能会写出 INSERT ... RETURNING，希望一条语句插入后直接得到完整行。MySQL 8.4 的结论很明确：INSERT 语法没有 RETURNING 子句，因此不能靠它直接返回写入后的行。正确做法是先拿到可定位这行的键，再在同一物理连接中执行 SELECT。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/insert.html

本文按一次排障复盘来拆：先看语法为什么失败，再分别处理新插入、重复键更新和多行插入，最后把连接池与事务边界补齐。

先看报错：RETURNING 为什么不是 MySQL INSERT 的一部分

故障通常出现在应用准备把“写入”和“回读”合成一条 SQL 时。MySQL 8.4 手册列出的 INSERT 形态包括 VALUES、SET、SELECT、TABLE，还可以接 ON DUPLICATE KEY UPDATE；语法定义里没有 RETURNING。所以这不是字段名、权限或自增配置问题，而是语句方言边界。

先把错误归类很重要：如果问题是语法不支持，继续调整 RETURNING id、RETURNING * 或字段顺序都不会解决。修复方向应当改成“两条语句共享一个连接”，而不是继续寻找 RETURNING 的写法。

故障触发条件：你到底要回读哪一种行

写入后回读并不只有一种情况。新行一般有一个刚生成的 AUTO_INCREMENT 主键；幂等写入可能没有插入，而是命中了唯一键并更新旧行；批量插入则可能同时生成多个主键。三种场景如果都只依赖“最后一个 ID”，很容易把结果读错。

这一步就是根因定位：缺少 RETURNING 不是“无法知道写入结果”，而是 MySQL 把键值回传和完整行查询拆成了两个接口。

修复路径：先拿到键，再读取完整行

对于单行新插入，先插入，再把会话级的自增值保存下来，最后按主键读取。LAST_INSERT_ID() 与当前客户端连接绑定，连接池不能在两条语句之间换连接。

-- 建表示例：id 由 MySQL 自动生成，code 作为业务字段
CREATE TABLE task_record (
    id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    code VARCHAR(64) NOT NULL,
    state VARCHAR(16) NOT NULL,
    UNIQUE KEY uk_task_code (code)
);

-- 写入一行；NULL 让 MySQL 生成 AUTO_INCREMENT 值
START TRANSACTION;
INSERT INTO task_record (id, code, state)
VALUES (NULL, 'task-20261026-01', 'ready');

-- 立即在同一物理连接保存刚生成的主键
SET @new_id = LAST_INSERT_ID();

-- 按主键读取数据库最终保存的完整行
SELECT id, code, state
FROM task_record
WHERE id = @new_id;
COMMIT;

应用层可以把 @new_id 换成驱动返回的 insert id，再绑定到第二条查询。事务不是为了模拟 RETURNING，而是把“写入后读取”放在一个清晰的工作范围内；如果读取结果后还要继续写关联表，也可以在读取完成后再提交。

重复键更新：让两条路径都能拿到主键

如果业务要求“有则更新、无则插入”，单纯调用驱动的 insert id 可能无法覆盖更新分支。可以在更新分支把已有主键传给 LAST_INSERT_ID(id)，这样新插入和命中旧行都能沿用同一个回读动作。

-- code 是业务唯一键；new 是待写入行的别名
INSERT INTO task_record (code, state)
VALUES ('task-20261026-01', 'running') AS new
ON DUPLICATE KEY UPDATE
    -- 命中旧行时把旧主键写入当前连接的 LAST_INSERT_ID()
    id = LAST_INSERT_ID(id),
    -- 只更新本次写入希望改变的字段
    state = new.state;

-- 无论新插入还是重复键更新，都按同一主键读取完整行
SET @resolved_id = LAST_INSERT_ID();
SELECT id, code, state
FROM task_record
WHERE id = @resolved_id;

这里的 id = LAST_INSERT_ID(id) 是有意的会话值设置，不是为了改变主键。不要把它写成无条件覆盖全部字段；更新哪些列仍应由业务语义决定。若表有多个唯一键，还要明确哪个冲突路径代表同一个业务对象，避免把“命中哪条唯一索引”留给猜测。

防复发：连接、多行和显式 ID 三个检查点

第一，保持同一物理连接。 INSERT 后立刻读取 LAST_INSERT_ID()；不要先把连接归还连接池，再由下一次查询重新取值。这个值是会话状态，不是全表最新 ID。

第二，别用一个 ID 代表多行。 MySQL 文档说明，多行 INSERT 时 LAST_INSERT_ID() 只返回第一条自动生成值。如果要读回所有行，应使用本次写入携带的业务唯一键集合查询，并在应用层按唯一键映射结果。

第三，留意显式 ID 和失败状态。 如果插入时指定了一个普通显式主键，不能把它当作“刚生成的自增值”；语句失败或回滚后，也不要继续使用旧的会话值。每次都应先判断写入结果，再决定是否执行回读。

排障时可以用下面这张最短清单：

• 语法报错：删除 RETURNING，改为键值回读。
• 读到空行：检查两条语句是否使用了同一个物理连接。
• 更新分支拿不到 ID：在重复键更新中设置 LAST_INSERT_ID(id)。
• 批量结果不全：不要依赖单个 LAST_INSERT_ID()，改用业务唯一键集合。

常见问题

MySQL 8.4 能不能写 INSERT ... RETURNING *

不能按 MySQL 8.4 的 INSERT 语法直接使用。需要完整行时，先取自增主键或业务唯一键，再执行 SELECT。

LAST_INSERT_ID() 会不会拿到别的客户端的 ID

不会。它是当前客户端连接的会话值；真正需要防范的是连接池在两条语句之间切换物理连接。

为什么不直接 SELECT MAX(id)

MAX(id) 只表示当前可见数据中的最大值，无法证明它属于刚才这次写入；并发写入时尤其不可靠。用当前连接返回的键或业务唯一键定位更稳妥。

总结

这次故障的根因不是 MySQL 不能读取写入后的行，而是把别的数据库的 RETURNING 语法套到了 MySQL。单行新插入用 LAST_INSERT_ID()，重复键更新用 LAST_INSERT_ID(id) 统一主键，再在同一物理连接中执行 SELECT；多行插入则用业务唯一键集合回读。把这三个边界写进数据访问层，类似报错就能快速定位。