MySQL INSERT ... RETURNING 为什么不能直接用：写入结果回取与替代方案边界

订单服务写入一行 orders 后，下一步通常要拿到自增 id 写入明细表或返回给调用方。把其他数据库里的 INSERT ... RETURNING id 原样搬到 MySQL 8.4，会直接遇到语法错误：MySQL 的 INSERT 语法没有这个通用返回子句。实际做法是让写入语句完成，再在同一连接里读取 LAST_INSERT_ID()，或者使用驱动提供的插入 ID 接口。

MySQL 里不要把 INSERT ... RETURNING 当成可移植语法；单行自增写入用同一连接紧接着读取 LAST_INSERT_ID()，多行写入则只把它当作首个生成 ID，不能猜出所有 ID。

先用一个订单写入例子确认语法边界

先准备一个足够小的表。order_no 负责业务幂等，id 只负责数据库内部关联：

CREATE TABLE orders (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL,
  buyer_id BIGINT UNSIGNED NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY uk_orders_order_no (order_no)
) ENGINE=InnoDB;

下面这句在支持 RETURNING 的数据库里很自然，但在 MySQL 8.4 中应先当成错误示例，不要放进生产重试逻辑：

INSERT INTO orders (order_no, buyer_id)
VALUES ('O202608280001', 42)
RETURNING id;

MySQL 官方的 INSERT 语法列出了 VALUES、SET、SELECT、TABLE 和 ON DUPLICATE KEY UPDATE 等形式，但没有 RETURNING。所以这不是权限、驱动或 SQL 模式的小差异，而是服务端语法能力不匹配。

单行写入：INSERT 后紧跟 LAST_INSERT_ID

最小替代方案是两条语句保持在同一数据库连接中：

INSERT INTO orders (order_no, buyer_id)
VALUES ('O202608280002', 42);

SELECT LAST_INSERT_ID() AS order_id;

这里的关键不是两条语句之间“距离很近”，而是它们必须由同一个连接完成。MySQL 会在连接会话中维护最近一次成功生成的自增值；另一个连接随后调用 LAST_INSERT_ID()，不会替你拿到这次写入的 ID。

应用代码里应把插入和取值封装成一个不可拆开的操作。以伪代码表达，LastInsertId 必须在写入返回成功后立刻调用：

result, err := db.ExecContext(ctx,
  "INSERT INTO orders (order_no, buyer_id) VALUES (?, ?)",
  orderNo, buyerID,
)
if err != nil {
  return err
}
orderID, err := result.LastInsertId()
if err != nil {
  return err
}

如果驱动或封装层不提供 LastInsertId，就继续用同一连接执行 SELECT LAST_INSERT_ID()。不要先把连接归还连接池，再借一个连接查询；那样读到的可能是另一个会话的历史状态。

多行 INSERT：首个 ID 不是全部结果

多行写入是最容易误判的地方：

INSERT INTO orders (order_no, buyer_id) VALUES
  ('O202608280003', 42),
  ('O202608280004', 43),
  ('O202608280005', 44);

SELECT LAST_INSERT_ID() AS first_order_id;

如果三行都成功，LAST_INSERT_ID() 返回第一条自动生成的 ID，而不是一个包含三项的结果集。即使某些场景下 ID 看起来连续，也不应在应用里用“首个 ID 加下标”补出全部主键：并发写入、显式 ID、INSERT IGNORE、触发器和自增分配策略都会让这种推断失去可靠性。

需要完整结果时，用业务唯一键在事务内回查

如果调用方必须拿到多行真实 ID，先给每行准备稳定的业务唯一键，再用事务包住写入与回查。示例中不依赖自增 ID 连号：

START TRANSACTION;

INSERT INTO orders (order_no, buyer_id) VALUES
  ('O202608280006', 42),
  ('O202608280007', 43);

SELECT id, order_no
FROM orders
WHERE order_no IN ('O202608280006', 'O202608280007');

COMMIT;

回查结果还要按 order_no 与输入集合逐项核对：数量不对、缺少某个业务键，或读到的记录状态不符合预期，都应让事务失败。这个方案比猜自增区间多一次查询，但表达的是业务事实，能适应重试和并发。

四个容易踩中的边界

• 连接池边界：INSERT 和 LAST_INSERT_ID() 不能拆到两个连接。
• 错误边界：写入返回错误后，不要继续使用上一次的插入 ID；官方文档将错误后的值视为未定义。
• 重复键边界：ON DUPLICATE KEY UPDATE 可能走更新分支，必须明确接口要返回“新建 ID”还是“已有 ID”。
• 批量边界：首个 ID 只说明首行自动生成值，不能证明每一行的主键。

常见问题

MySQL 8.4 以后会自动支持 INSERT RETURNING 吗？

不能根据其他数据库的语法推断 MySQL 的版本计划。当前写法应以对应版本官方 INSERT 语法为准；在未确认支持前，继续使用驱动插入 ID或同连接查询。

LAST_INSERT_ID() 会被别的客户端覆盖吗？

不会跨连接互相覆盖。它维护在当前客户端连接的会话上下文中，但这也意味着连接切换后不能继续依赖原值。

批量写入后怎样拿到每一行 ID？

不要从首个 ID 推算。使用业务唯一键在同一事务内回查，或让应用在写入前生成稳定业务标识并建立映射。

总结

MySQL 的替代路径很明确：单行写入拿驱动返回的插入 ID；需要 SQL 结果时，在同一连接紧接着读 LAST_INSERT_ID()；批量写入不要假设自增连续，用业务唯一键回查完整集合。这样既尊重 MySQL 8.4 的实际语法，也把连接、错误和重复键边界留在了可验证的位置。