当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 插入或更新后怎么拿到已有主键：LAST_INSERT_ID(id) 与并发验收

MySQL 插入或更新后怎么拿到已有主键：LAST_INSERT_ID(id) 与并发验收

来源：17golang原创 2026-08-28 12:43:22 0浏览收藏

保存一条带业务唯一键的记录时，接口通常只想拿到一个结果：这次保存对应的数据库主键。新建行可以从自增列得到 id，命中已有行时却不能假定客户端已经知道它的主键。MySQL 可以把更新分支写成 id = LAST_INSERT_ID(id)，让两条路径都把主键放进当前连接的最后插入值。

把 LAST_INSERT_ID(id) 放在重复键更新分支，并在同一条连接上立刻读取结果，可以让新增和复用记录统一返回主键；它解决的是结果回传，不是替代事务边界。

实践要点

业务唯一键必须有真正的 UNIQUE 约束，不能只在应用层判断不存在。
LAST_INSERT_ID(expr) 的值属于当前客户端连接，读取动作不能换到另一条连接。
重复键分支更新的是同一行的 id，不会创建第二条记录，但仍需核对其他字段的更新语义。
批量写入、触发器和跨连接异步读取有额外边界，不能直接套用单行写法。

先把保存目标限定为一行

示例表用 account_code 表示外部系统带来的稳定编号。先建立唯一约束，后面的重复键分支才有确定的触发条件：

CREATE TABLE account (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  account_code VARCHAR(64) NOT NULL,
  display_name VARCHAR(128) NOT NULL,
  updated_at TIMESTAMP NOT NULL,
  UNIQUE KEY uk_account_code (account_code)
);

这里的业务假设是：同一个 account_code 只能对应一行，名称和更新时间允许被后续保存动作更新。若业务允许同码多行，这个方案就失去了“返回哪一行”的基础。

新增与命中旧行的最小写法

把写入和重复键处理放在同一条语句里，更新分支显式把已有主键传给 LAST_INSERT_ID：

INSERT INTO account (account_code, display_name, updated_at)
VALUES ('A-1007', '仓储一组', CURRENT_TIMESTAMP)
ON DUPLICATE KEY UPDATE
  id = LAST_INSERT_ID(id),
  display_name = VALUES(display_name),
  updated_at = VALUES(updated_at);

SELECT LAST_INSERT_ID() AS account_id;

第一次写入时，AUTO_INCREMENT 生成的新值成为最后插入值；如果 uk_account_code 冲突，MySQL 锁定待更新的已有行，LAST_INSERT_ID(id) 把这一行的主键写入当前连接。最后的 SELECT 只负责读结果，不再按业务键查一次。

MySQL INSERT ON DUPLICATE KEY UPDATE 从业务唯一键到 LAST_INSERT_ID 主键返回的调用链示意图

为什么读取动作必须留在同一条连接

LAST_INSERT_ID() 保存的是会话状态，不是一个可以被所有连接共同读取的全局变量。连接池场景里，如果写入由连接 A 完成、读取由连接 B 完成，B 可能读到自己的历史值，甚至读到零。

应用层应把“执行保存语句”和“读取 LAST_INSERT_ID()”绑定到同一个连接对象。很多驱动也会直接暴露插入 ID，但要确认驱动取的是当前语句的 OK 结果，并且没有在中间插入 SELECT、心跳或切换数据库的动作。

把并发验收拆成三个阶段

并发测试不要只看接口返回值，至少记录唯一键、返回的 account_id 和表内最终行数。

第一阶段：确认唯一约束真的生效

清空测试数据后，让两个客户端同时写入 A-1007。预期结果是表里只有一行，两个客户端返回同一个 account_id。如果出现两行，先查表结构和索引，而不是继续改读取代码。

第二阶段：确认更新字段符合业务意图

重复键分支不只是在“找 ID”，示例中的 display_name 和 updated_at 也会更新。若只想复用主键而不覆盖名称，应删除对应赋值，或改成带条件的更新表达式。先确定写入语义，再决定是否使用这条单语句。

第三阶段：确认连接没有被换走

在测试日志中打印连接标识、业务唯一键和返回 ID；不要把真实凭据写进日志。随后执行：

SELECT id, account_code, display_name
FROM account
WHERE account_code = 'A-1007';

SELECT COUNT(*) AS same_code_rows
FROM account
WHERE account_code = 'A-1007';

结果应同时满足：same_code_rows = 1，接口返回的 account_id 等于查询出的 id，并且字段内容符合这次保存的更新规则。

MySQL 重复键并发写入经过唯一键锁定后在同一连接核对 account_id 的验收路径

三个容易误用的边界

不要把应用层先查再写当成唯一保护

“先 SELECT，不存在再 INSERT”在并发下会让两个请求同时看到不存在。唯一索引和单条写入才是冲突收敛点，应用层查询只能用于展示或补充校验。

批量语句不要假设只返回一个 ID

多行 INSERT 可能产生多个自增值，而 LAST_INSERT_ID() 只代表该语句规则下的一个值。批量导入如果需要逐条映射，应使用业务键回查、分批写入或驱动明确支持的返回机制。

触发器和存储过程要单独核对

存储过程、函数和触发器对最后插入值的可见范围并不完全相同。不要仅凭单元测试中的普通 SQL 结果推断封装后的行为；把实际调用路径纳入集成测试。

什么时候改用写入后查询

如果保存动作还要经过复杂的条件更新、需要返回多列计算结果，或者驱动已经提供可靠的原生返回行能力，写入后按唯一键查询会更直观。此时查询必须使用同一事务和合适的隔离边界，避免把“刚才写的行”误读成另一种状态。

LAST_INSERT_ID(id) 更适合单行幂等保存：唯一键明确、主键只需返回一个、更新字段可控、应用能保证连接连续。它是一个窄而实用的结果回传技巧，不应被包装成通用并发方案。

小结

用唯一索引约束业务键，用 INSERT ... ON DUPLICATE KEY UPDATE 收敛新增和复用路径，再用 id = LAST_INSERT_ID(id) 统一返回主键。验收时重点看同一连接、唯一键下的单行结果和更新字段语义；遇到批量写入、复杂返回或封装调用，则应重新评估更清晰的事务查询方案。