必须依赖显式时间戳或自增主键才能可靠定位最后插入记录；直接order by id desc limit 1不可靠，因id未必自增、可能存在删除空洞、并发下生成与提交顺序不一致；最稳妥方案是使用created_at timestamp default current_timestamp并order by created_at desc, id desc。
没有通用的“最后插入”语义，SQL标准不保证插入顺序可被自动识别；必须依赖显式的时间戳或自增主键才能可靠定位。
为什么不能直接用 SELECT * FROM table ORDER BY id DESC LIMIT 1？
这个写法看似合理，但存在几个关键前提漏洞：
-
id字段未必是自增主键（可能是 UUID、业务编码、手动赋值） - 即使
id是自增，如果发生过DELETE+INSERT或主从延迟，MAX(id)对应的记录未必是“最后插入”的那条 - 多个会话并发插入时，
id生成顺序 ≠ 提交顺序（尤其在使用AUTO_INCREMENT偏移或组提交场景下）
真正可靠的方案：必须有时间戳字段
最稳妥的方式是表中存在一个 created_at（或类似命名）字段，并在插入时由数据库自动填充（如 MySQL 的 CURRENT_TIMESTAMP）：
INSERT INTO users (name, email) VALUES ('Alice', 'a@example.com');
对应建表语句需确保该字段定义为：
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
查询时用：
SELECT * FROM users ORDER BY created_at DESC LIMIT 1;
注意点：
- 务必确认
created_at是INSERT时写入，而非应用层生成（否则受客户端时钟偏差影响） - 若字段类型是
DATETIME，MySQL 5.6+ 才支持DEFAULT CURRENT_TIMESTAMP；旧版本需用触发器或应用层补全 - 高并发下，微秒级重复值仍可能发生，此时需联合
id二次排序：ORDER BY created_at DESC, id DESC
没有时间戳？只能靠自增主键 + 严格约束
仅当满足以下全部条件时，MAX(id) 才可近似代表最后插入：
-
id是INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY - 无手工
INSERT ... VALUES (xxx)指定id的操作 - 无
TRUNCATE TABLE或ALTER TABLE ... AUTO_INCREMENT = N等重置行为 - 业务上不依赖“逻辑删除”，即不保留已删记录的
id空洞
即便如此，仍建议加 WHERE id = (SELECT MAX(id) FROM table) 而非 LIMIT 1，避免索引失效导致全表扫描。
PostgreSQL / SQL Server 等其他数据库的特殊处理
PostgreSQL 可用 RETURNING 在插入时直接拿到新记录：
INSERT INTO users (name, email) VALUES ('Bob', 'b@example.com') RETURNING *;
SQL Server 2005+ 支持 OUTPUT 子句实现类似效果；但这些都只适用于“刚插入后立刻查”，无法回溯历史。如果要查任意时刻的最后一条，依然绕不开时间戳或可靠序列字段。
实际工程中，别寄希望于“隐式顺序”——要么加 created_at，要么改用 serial/IDENTITY 配合严格写入规范。漏掉这个字段的设计，后续排查成本远高于初期多写一行 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP。
