LAST_INSERT_ID() 返回当前会话最近一次自增插入生成的ID，会话级、不依赖表名、不加锁；不可用SELECT MAX(id)替代，因其并发不安全；事务回滚后值仍保留但ID作废；批量插入时返回首行ID。
MySQL 中 LAST_INSERT_ID() 的基本用法
执行 INSERT 后立刻调用 LAST_INSERT_ID()，就能拿到本次会话中最后一条 INSERT 生成的自增 ID。它不依赖表名、不查表、不加锁，只返回当前连接上下文里最近一次由 MySQL 自动分配的自增值。
关键点在于：这个函数是**会话级**的，且只对真正触发自增列插入的行为生效（比如 INSERT INTO t(id, name) VALUES(NULL, 'a') 或省略自增列的写法）。
-
INSERT INTO user(name) VALUES('alice')→ 可用LAST_INSERT_ID() -
INSERT INTO user(id, name) VALUES(100, 'bob')→ 不更新LAST_INSERT_ID()（除非显式设置id=0或NULL且启用了NO_AUTO_VALUE_ON_ZERO） - 同一连接中执行多条
INSERT，每次调用都返回对应那条语句产生的 ID，不是“全局最大 ID”
为什么不能用 SELECT MAX(id) 替代
看似简单，但 SELECT MAX(id) 在并发场景下极不可靠：你刚插入一条记录，还没来得及查，另一个连接又插了一条，MAX(id) 就变成它的了。这不是竞态，是确定性错误。
而 LAST_INSERT_ID() 是服务器内部维护的会话变量，不受其他连接干扰，也不受事务是否提交影响（即使事务回滚，该值仍保留为插入时的 ID，但此时这个 ID 实际已作废——这点常被忽略）。
- 事务未提交时调用
LAST_INSERT_ID()→ 返回正常 - 事务回滚后调用 → 仍返回原值，但该 ID 已不会出现在表中
- 跨连接调用 → 永远得不到别人插入的 ID
在不同客户端中的实际调用方式
函数本身是 SQL 级的，但调用时机和封装方式因语言而异。核心原则只有一条：必须在同一次数据库连接中，在 INSERT 之后、其他写操作之前执行查询。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
例如在 PHP PDO 中：
INSERT INTO post(title) VALUES('hello');
$lastId = $pdo->lastInsertId(); // 底层就是 SELECT LAST_INSERT_ID()Python MySQLdb 或 PyMySQL 中：
cursor.execute("INSERT INTO post(title) VALUES(%s)", ['hello'])
last_id = cursor.lastrowid # 多数驱动自动映射到 LAST_INSERT_ID()- 不要写成
SELECT LAST_INSERT_ID()再用fetchone()—— 多数驱动提供更直接的接口 - 如果手动执行
SELECT LAST_INSERT_ID()，确保在同一个cursor或连接上，且中间没穿插别的INSERT - 批量插入（
INSERT ... VALUES(...),(...)）时，LAST_INSERT_ID()返回的是第一行生成的 ID，不是最后一条
容易被忽略的边界情况
最常踩坑的是以为 LAST_INSERT_ID() 是“表级”或“事务级”函数。其实它只认“本连接 + 最近一次自增插入”，哪怕中间混了存储过程、触发器、甚至 REPLACE INTO，行为都可能出人意料。
-
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE：若发生替换并导致新行插入，则更新LAST_INSERT_ID()；若仅更新旧行，则不更新 - 触发器里再插入另一张表 → 会覆盖当前连接的
LAST_INSERT_ID()值 - 显式插入
0或负数到自增列 → 默认被转为下一个自增值，但LAST_INSERT_ID()仍返回实际插入的值（即 0 或负数），除非设置了sql_mode=NO_AUTO_VALUE_ON_ZERO
如果你需要可靠获取刚插入的 ID，就别绕弯子——插完立刻取，别跨语句、别跨连接、别信 MAX()，也别假设触发器不会动它。
