last_insert_id()在批量插入时只返回第一条记录的自增id，而非最大值或全部id；它绑定当前连接、不跨事务、不因回滚重置，且易被后续插入覆盖，故须紧接insert后立即获取。
批量插入时 LAST_INSERT_ID() 返回第一个 ID，不是最大值
执行 INSERT INTO t (name) VALUES ('a'), ('b'), ('c') 后，LAST_INSERT_ID() 返回的是这一批中**第一行实际分配到的自增 ID**，比如 100，而不是 102。它不关心你插了几行，只认“本次 INSERT 语句生成的第一个自增值”。
常见错误现象：用这个值去判断“最后一条是否成功插入”，或者当成“本次插入的最大 ID”来分页、校验——这会出错。因为 100～102 都已写入，但函数只告诉你起点。
- 即使表里已有 ID 99，新批量插入从 100 开始，
LAST_INSERT_ID()就是 100 - 如果中间有跳号（比如因
innodb_autoinc_lock_mode = 2导致分配了 100、101、104），它仍返回 100 - 显式指定部分 ID（如
VALUES (105, 'x'), (NULL, 'y')）时，只有NULL触发自增，LAST_INSERT_ID()返回那个自增出来的值（比如 106），不是 105
为什么不能在 INSERT 后隔几条语句再调用
必须在同一次数据库连接中、紧接在 INSERT 之后立刻获取。中间哪怕只执行一条 UPDATE 或另一个 INSERT，只要它也触发了自增，LAST_INSERT_ID() 就会被覆盖。
典型坑：事务中先插 A 表，再插 B 表并想用 A 的 ID 做外键，结果在 B 插完后才查——此时拿到的是 B 表的 ID，不是 A 的。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- PHP 中应直接用
$pdo->lastInsertId()或$mysqli->insert_id，而不是写SELECT LAST_INSERT_ID() - 用连接池时，上一个请求留下的值可能还在，务必在获取连接后立即读取或重置（例如执行
SELECT LAST_INSERT_ID(0)） - 事务回滚不影响该值：ID 已分配且不可回收，
LAST_INSERT_ID()仍返回那个作废的值
LAST_INSERT_ID(expr) 能强行改写返回值
你可以用 LAST_INSERT_ID(123) 主动设置会话级变量，之后调用无参 LAST_INSERT_ID() 就返回 123。这在某些场景下有用，比如模拟插入、绕过自增逻辑做外键关联。
但要注意：这个设置是会话级的，且会覆盖之前所有自动产生的值；一旦设了，后续真正的 INSERT 也不会自动更新它，除非你再执行一次无参调用或另一次 INSERT。
-
LAST_INSERT_ID(456)之后，SELECT LAST_INSERT_ID()返回 456 - 接着执行
INSERT INTO t (name) VALUES ('test')，新 ID 是 457，但LAST_INSERT_ID()仍为 456 —— 直到你再次调用它（这时才刷新为 457） - 别在触发器或存储过程中随意用这个，容易污染父上下文的值
什么情况下根本拿不到预期的 ID
当业务涉及并发写、跨服务协调、或主键不用 AUTO_INCREMENT 时，LAST_INSERT_ID() 就不够用了。它只保证“本连接最近一次自增插入的第一个 ID”，不保证原子性、不跨连接、也不反映当前表最大 ID。
比如用 UUID 或雪花 ID 当主键，LAST_INSERT_ID() 根本不生效；又比如批量导入脚本分多线程跑，每个线程都得自己维护 ID 映射，不能靠这个函数同步。
- 不要依赖它做分布式 ID 分配
- 不要用它替代
SELECT MAX(id)（后者慢、不准、有竞态） - 真正需要“全部插入 ID 列表”时，得用应用层生成 ID（如提前
SELECT AUTO_INCREMENT FROM information_schema.TABLES预占范围），或改用返回多值的方案（如 PostgreSQL 的RETURNING）
