应优先使用 created_at 时间戳字段并建立索引，而非依赖 id 排序；因 id 可能不连续、被跳过或非单调递增，仅在单机自增 ID 且无手动插入时 ORDER BY id DESC 才可靠。
直接用 ORDER BY id DESC 最简单，但得确认 ID 是自增且连续插入
绝大多数情况下，“最近插入的数据” ≈ “ID 最大的那几条”，前提是表的 id 是 AUTO_INCREMENT（MySQL）、IDENTITY（SQL Server）或序列驱动（Oracle），且没有大量删除、手动插入或并发写入导致 ID 乱序。
常见错误现象：
– 查询结果里看到的是“很早以前的记录”
– ORDER BY id DESC LIMIT 10 返回的不是你刚插的那批数据
– 多个服务同时写入时，ID 高 ≠ 时间近（尤其用了分库分表或 UUID 主键）
- 只在单机 MySQL/PostgreSQL 表且无显式指定
id值时，ORDER BY id DESC才可靠 - 如果业务允许，建议加一个
created_at时间戳字段，并建索引：CREATE INDEX idx_created_at ON table_name(created_at DESC) - Oracle 不要依赖
ROWNUM或ROWID排序，它们不反映插入时间；必须靠ORDER BY created_date DESC或序列值 + 时间双保险
LAST_INSERT_ID() 只返回当前连接最后插入的 ID，不能查“最近一批”
很多人误以为 LAST_INSERT_ID() 能查出“最近插入的几条记录”，其实它只返回本连接中最后一次 INSERT 生成的那个 ID —— 即便你一次插了 100 条，它也只记最后一个。
使用场景：
– 插完立刻要拿这个 ID 做关联插入（比如主从表）
– 不适合做“查询最近 N 条”的依据
- 不同连接之间互不影响：
connection A插完得到 1005，connection B插完得到 1006，各自调LAST_INSERT_ID()拿到的仍是自己的值 - 如果执行了
INSERT ... SELECT或批量插入，LAST_INSERT_ID()返回的是第一行生成的 ID（MySQL 行为），不是最大 ID - SQL Server 用
SCOPE_IDENTITY()更安全，@@IDENTITY会被触发器干扰
想查“最近 10 条”，别只靠 ID，优先加时间字段并索引
靠 id 排序本质是偷懒替代方案。真实系统里，ID 可能被跳过（事务回滚、批量导入跳号）、被复用（某些 Oracle 序列配置）、或根本不是单调递增（UUID、雪花 ID）。
性能影响：
– 如果只有 id 索引，ORDER BY id DESC LIMIT 10 很快
– 但如果还要过滤状态、用户等条件，没 created_at 索引就容易全表扫描
- 建表时务必包含
created_at DATETIME DEFAULT CURRENT_TIMESTAMP - 查询语句写成：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 - 复合索引更实用：
INDEX idx_user_time (user_id, created_at DESC)，支持“查某用户最新 10 单”这种高频场景
Oracle 和 SQL Server 获取刚插入记录，OUTPUT 和 RETURNING 比查 ID 更准
当你要“插入后立刻拿到完整新记录”，而不是事后靠 ID 去查，就得用数据库原生的返回机制 —— 这比插完再 SELECT MAX(id) 安全得多，彻底避开并发竞争和 ID 冲突。
参数差异：
– SQL Server 用 OUTPUT inserted.*
– PostgreSQL 用 RETURNING *
– MySQL 8.0.20+ 支持 RETURNING，但老版本只能靠 LAST_INSERT_ID() + 再查
- SQL Server 示例：
INSERT INTO users(name) OUTPUT inserted.* VALUES ('Alice') - PostgreSQL 示例：
INSERT INTO users(name) VALUES ('Bob') RETURNING * - Oracle 用
RETURNING id INTO :var绑定变量，不能直接返回整行，需额外声明
容易被忽略的一点：这些语法都要求在同一个语句内完成插入与返回，没法拆成两条独立 SQL —— 所以 ORM 框架若不显式支持，就得手写原生语句或换用存储过程。
