LAST_INSERT_ID()是MySQL中唯一可靠获取刚插入自增ID的方式，它返回当前会话最近一次成功INSERT生成的自增值，不查表、并发安全、不受其他客户端干扰，但必须在同一连接中紧接INSERT后调用。
用 LAST_INSERT_ID() 获取刚插入的自增ID
MySQL 存储过程中，只要上一条语句是 INSERT（且影响了自增列），调用 LAST_INSERT_ID() 就能拿到那个 ID。它不依赖连接中的其他操作，也不受其他客户端干扰——这是 MySQL 内部为每个连接维护的独立值。
关键点：这个函数返回的是「当前会话中最近一次成功 INSERT 生成的自增值」，不是 SELECT 最后一行的 ID，也不是表里最大的 ID。
常见误用场景：
- 在
INSERT ... SELECT多行插入后调用，只返回第一条生成的 ID（不是最大值，也不是行数） - 在触发器或另一个存储过程里执行了 INSERT，再回到原过程查
LAST_INSERT_ID()，值已被覆盖 - 误以为
SELECT MAX(id)更可靠——并发下可能拿到别人刚插的 ID
必须在同个会话、紧接 INSERT 后调用
一旦中间执行了任何其他 INSERT（哪怕是对另一张表）、或调用了其他修改自增值的语句（如 REPLACE、INSERT ... ON DUPLICATE KEY UPDATE），LAST_INSERT_ID() 就会被重置。
实操建议：
- 把
SELECT LAST_INSERT_ID()或直接赋值给变量写在INSERT语句之后、其他 DML 之前 - 不要跨语句块缓存——比如在 IF 分支里 INSERT，却在 END IF 之后才取 ID
- 如果需要多次使用，立刻存进局部变量：
SET @new_id = LAST_INSERT_ID();
示例片段：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
INSERT INTO users (name, email) VALUES ('Alice', 'a@example.com');
SET new_user_id = LAST_INSERT_ID();
INSERT INTO profiles (user_id, bio) VALUES (new_user_id, 'Hello world');
LAST_INSERT_ID() 和 @@IDENTITY 的区别
两者都返回自增 ID，但行为差异极大：
-
LAST_INSERT_ID()只响应显式指定的自增列插入，且不受触发器内 INSERT 影响 -
@@IDENTITY会“穿透”到触发器里——如果 INSERT 触发了一个往另一张表插入的操作，它返回的是触发器里那条的 ID，不是原始语句的 - 多数情况下应优先用
LAST_INSERT_ID()，除非你明确需要捕获触发器产生的 ID
一个典型坑：用户表有触发器自动往日志表插入，用 @@IDENTITY 取 ID 会得到日志表的 ID，导致后续逻辑错乱。
批量插入时 LAST_INSERT_ID() 返回什么？
对 INSERT INTO t (a) VALUES (1),(2),(3) 这种单语句多行插入，LAST_INSERT_ID() 返回的是**第一行生成的 ID**，不是最后一条，也不是总行数。
如果你需要全部 ID，MySQL 本身不提供直接方式——得靠业务层控制，比如：
- 拆成单条 INSERT 循环，每次取一次
LAST_INSERT_ID() - 用临时表 + 自增模拟，再 JOIN 查询
- 改用 UUID 或应用层生成 ID（避开自增依赖）
注意：INSERT ... SELECT 批量导入也遵循同样规则，只返回首行 ID。
真正容易被忽略的是：这个“首行 ID”取决于表的自增起始值和当前 AUTO_INCREMENT 值，不是插入数据的顺序或内容——如果中间有 DELETE 导致空洞，它仍按自增计数器推进。
