LAST_INSERT_ID()是MySQL 5.7中唯一可靠获取刚插入自增ID的方式，它基于会话级状态，不受触发器、并发或显式指定ID干扰；而@@IDENTITY易受触发器内插入影响，SELECT MAX(id)在并发、删除或事务未提交时不可靠。
存储过程中必须用 LAST_INSERT_ID()，不能用 @@IDENTITY
在 MySQL 5.7 中，LAST_INSERT_ID() 是唯一可靠的方式——它基于连接（connection）维护状态，不会被触发器、其他表的插入或并发操作干扰。而 @@IDENTITY 会受触发器中隐式插入的影响，比如你往 orders 表插一条记录，触发器又往 order_logs 插了一条带自增 ID 的日志，此时 @@IDENTITY 返回的是日志表的 ID，不是你想要的订单 ID。
实操要点：
-
LAST_INSERT_ID()必须紧跟在INSERT语句之后调用，中间不能有其他影响自增计数器的操作（如另一条 INSERT、UPDATE 自增列等） - 不需要加
SELECT就能直接赋值：SET new_id = LAST_INSERT_ID(); - 如果一次插入多行（
INSERT INTO t VALUES (),(),()），该函数返回的是**第一行生成的 ID**，不是最大值
存储过程里怎么安全返回这个 ID
最常用且明确的方式是用 OUT 参数接收，避免依赖客户端解析结果集。示例：
DELIMITER //
CREATE PROCEDURE insert_user(
IN p_name VARCHAR(50),
OUT new_id INT
)
BEGIN
INSERT INTO users(name) VALUES (p_name);
SET new_id = LAST_INSERT_ID();
END //
DELIMITER ;
调用时注意变量绑定：
CALL insert_user('Alice', @new_id);
SELECT @new_id;
常见错误：
- 忘记声明
OUT参数类型，导致返回NULL - 调用后没执行
SELECT @new_id，误以为没拿到值（其实已存入会话变量） - 在事务中插入后又执行了其他 INSERT，再取
LAST_INSERT_ID()就错了
为什么不能用 SELECT MAX(id) 替代
在存储过程里写 SELECT MAX(id) INTO new_id FROM users 看似简单，但实际非常危险：
- 高并发下可能读到其他连接刚插入但尚未提交的 ID（取决于隔离级别），也可能漏掉已提交但还没刷盘的行
- 如果中间有人删过数据，
MAX(id)和下一个自增 ID 差距可能很大（比如删了 id=100 的行，下个自增仍是 101） - 无法区分“刚插的那条”和“表里最大的那条”，逻辑上就不等价
只有在极低频、单线程、且不关心原子性的调试场景下才可临时用，生产环境禁止。
LAST_INSERT_ID() 在 MySQL 5.7 中的几个关键行为
这些细节决定你能不能写出稳定的存储过程：
- 它是会话级函数，每个连接独立维护，不受其他客户端影响
- 即使插入时显式指定了 ID（如
INSERT INTO t(id, name) VALUES(999, 'x')），只要该值非 0 且非 NULL，LAST_INSERT_ID()仍返回你指定的值（不是自动生成的） - 如果插入时用了
NULL或0触发自增，则返回新生成的 ID；但如果用0且表定义为NOT NULL，会报错，函数也不生效 - 重启 MySQL 5.7 实例后，计数器从当前表最大 ID +1 开始（因为未持久化），所以
LAST_INSERT_ID()不会回退，但初始值可能跳变
真正容易被忽略的是：它只对「最近一次成功插入」有效，且不感知事务回滚——如果插入后又 ROLLBACK，该函数仍返回那个已失效的 ID。所以务必确保在 COMMIT 前就取值，并在业务逻辑里确认插入确实成功。
