LAST_INSERT_ID()是MySQL中唯一可靠获取刚插入自增ID的方式，它返回当前会话最近一次成功INSERT生成的第一个自增值，不跨连接、不依赖表名、不受并发干扰；PHP应使用$pdo->lastInsertId()等驱动原生方法，禁用SELECT LAST_INSERT_ID()查询。
INSERT 后立刻用 LAST_INSERT_ID() 拿 ID
MySQL 提供了 LAST_INSERT_ID() 这个函数，它返回当前会话中最近一次 INSERT 语句生成的自增主键值。关键点在于：它不依赖表名、不跨会话、也不受其他连接干扰——只要你在同一次连接里执行完 INSERT，立刻调用它，就准没错。
常见错误是插入后去查 MAX(id) 或用 SELECT id FROM table ORDER BY id DESC LIMIT 1，这在并发写入时大概率拿错 ID，绝对要避开。
- 必须在同一个数据库连接（connection）中调用，不同连接之间互不影响
- 即使 INSERT 失败（比如违反唯一约束），
LAST_INSERT_ID()也不会更新 - 批量插入（如
INSERT INTO t VALUES (),(),()）时，它返回的是第一个生成的 ID，不是最后一个 - 如果 INSERT 语句显式指定了自增列的值（比如
INSERT INTO t(id, name) VALUES (100, 'a')），LAST_INSERT_ID()仍会返回该显式值（前提是该值大于当前 AUTO_INCREMENT 值）
在不同客户端里怎么安全取值
实际开发中，你不会手动去连 MySQL 控制台再敲 SELECT LAST_INSERT_ID()。重点是让驱动或 ORM 正确拿到这个值。
- PHP PDO：执行
$pdo->lastInsertId()，底层就是调用LAST_INSERT_ID() - Python MySQLdb / PyMySQL：用
cursor.lastrowid，它映射到同一机制 - Java JDBC：调用
Statement.getGeneratedKeys()，这是标准方式，但底层仍依赖LAST_INSERT_ID()（MySQL Connector/J 默认启用） - Node.js mysql2：用
result.insertId字段，它直接从协议响应里解析出来，比查函数更轻量
注意：有些旧版驱动（比如老版本的 mysqljs/mysql）在开启 multipleStatements: true 时，insertId 可能失效，因为协议解析被干扰；建议关掉多语句或升级驱动。
为什么不能用 SELECT MAX(id) 或子查询
看起来简单直接，但本质不可靠。比如两个事务几乎同时插入：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
INSERT INTO user(name) VALUES ('Alice'); -- 生成 id=1001
INSERT INTO user(name) VALUES ('Bob'); -- 生成 id=1002
如果 A 插入后还没提交，B 就执行 SELECT MAX(id)，可能拿到 1001（A 的未提交记录对 B 不可见），也可能拿到 1000（取决于隔离级别和 MVCC 状态）。结果完全不可预测。
-
LAST_INSERT_ID()是会话级变量，只读自己刚干的事 -
SELECT MAX(id)是全表扫描，性能差，还带竞争条件 - 用
SELECT id FROM user WHERE name = 'xxx' ORDER BY id DESC LIMIT 1更糟：name 不一定唯一，且没索引的话就是全表扫
事务里插入失败时 LAST_INSERT_ID() 怎么变
它只在真正成功生成新 ID 时才更新。比如：
- INSERT 因主键冲突/外键失败/字段超长等报错 →
LAST_INSERT_ID()保持不变 - INSERT 成功但随后 ROLLBACK → 已分配的自增 ID 不会回收，
LAST_INSERT_ID()仍保留那个值（下次 INSERT 会继续 +1） - 如果你在事务中反复 INSERT 又回滚，自增计数器仍会往前走，导致 ID “空洞”，这是 MySQL 正常行为，不是 bug
所以别指望靠 LAST_INSERT_ID() 判断上一条是否成功——得先检查 SQL 执行结果是否报错。
