MySQL 中 LAST_INSERT_ID() 返回什么值
它返回当前会话（connection）中最近一次 INSERT 或 REPLACE 语句生成的自增主键值，**不是全局最大 ID，也不是表里最新那条记录的 ID**。哪怕你刚插入了一条记录，但中间执行过没用自增字段的 INSERT（比如显式指定了 id），LAST_INSERT_ID() 也不会变。
常见错误现象：
– 多线程/多连接环境下误以为能跨会话取 ID
– 在触发器或存储过程中调用后，被后续语句覆盖
– 执行了 INSERT ... SELECT 且没产生新自增值，结果还是旧值
- 只对
AUTO_INCREMENT字段生效；如果INSERT显式写了id值，不更新LAST_INSERT_ID() - 同一会话中，多次
INSERT后调用，只返回最后一次成功插入产生的 ID - 即使
INSERT失败（如唯一键冲突），只要没真正插入行，LAST_INSERT_ID()不变
PHP 中怎么安全拿到刚插入的 ID
别直接查 SELECT LAST_INSERT_ID()，而要用数据库扩展提供的原生方法——它们内部做了会话绑定和类型处理，更可靠。
- MySQLi 面向对象风格：
$mysqli->insert_id（执行INSERT后立即读，不要等其他查询） - PDO：
$pdo->lastInsertId()（注意：不带括号参数；传字符串会报错） - 不要用
mysql_query("SELECT LAST_INSERT_ID()")—— 这是老版本废弃 API，且容易因并发或中间查询污染结果
性能影响很小，但关键在于「时序」：必须在同一次数据库连接中、紧接在 INSERT 之后获取。中间夹了别的写操作（哪怕只是 UPDATE），只要没触发新的自增，值就不变；但一旦有别的 INSERT，就覆盖了。
为什么在事务里调用有时拿不到预期值
事务不影响 LAST_INSERT_ID() 的行为逻辑，但它放大了“调用时机”问题。很多人在 COMMIT 之后才去取，其实早该在 INSERT 执行完就拿了。
-
START TRANSACTION和INSERT之间不能有其它修改语句干扰自增计数 - 如果事务回滚（
ROLLBACK），已分配的自增值不会回收，但LAST_INSERT_ID()仍保留那个值——它反映的是“曾生成过”，不是“当前有效” - 在存储过程中用
LAST_INSERT_ID()，要确认是否被子过程或触发器里的INSERT覆盖
一个典型坑：在事务中插入 A 表，接着插入 B 表并想用 A 的 ID 做外键，却在 B 插入后再去查 LAST_INSERT_ID() —— 此时返回的是 B 表的 ID，不是 A 的。
替代方案：什么时候不该依赖 LAST_INSERT_ID()
当你的业务需要确保“刚插进去的那条记录的 ID”，又存在并发写、批量插入、或跨服务协调时，LAST_INSERT_ID() 就不够用了。
- 批量插入多行（
INSERT INTO t VALUES (),(),()）：它只返回第一行的 ID，不是全部 - 使用 UUID 或雪花算法做主键时，根本没
AUTO_INCREMENT，LAST_INSERT_ID()没意义 - 分库分表场景下，各节点自增独立，这个函数只对单库有效
- 想通过 ID 反查刚插入的数据？不如用
SELECT ... FOR UPDATE加锁后查，或者插入前生成 ID（如UUID()）再插入
最常被忽略的一点：它不校验数据一致性。拿到 ID 后立刻查记录，可能查不到——因为还没提交，或被其他事务隔离级别挡住。真要强一致，得结合事务隔离等级和显式查询来验证。
