最稳方法是子查询select id from t where id ? order by id asc limit 1；二者均需确保id有索引且排序明确。
子查询怎么拿到上一条记录的 id
直接用 WHERE id 是最稳的，别想用 <code>LAG() 或窗口函数——那是 PostgreSQL/MySQL 8.0+ 才支持的，老版本或兼容性场景下必须靠自增 id 排序和子查询硬刚。
关键点在于：上一条 = 当前 id 小于目标值的最大那个。所以子查询得写成独立语句，不能和主表共用别名。
常见错误是写成：SELECT * FROM t WHERE id = (SELECT id FROM t WHERE id ，看起来对，但一旦 <code>id 不连续（比如删过数据），它就真只找“数值上最接近”的那个，而不是“逻辑顺序上紧邻的上一条”——这恰恰是我们要的效果，只要确认业务里 id 是单调递增且用于排序的，就没问题。
- 必须加
ORDER BY id DESC，否则LIMIT 1结果不确定 - 子查询不能引用外层表字段（如
t.id），除非用相关子查询并明确关联，但那样性能差、易出错，不推荐 - 如果主键不是
id或不是自增整数，这个方法失效，得换时间戳或唯一序号字段
子查询怎么查下一条记录的 id
同理，下一条 = 当前 id 大于目标值的最小那个，语句就是把方向反过来：SELECT id FROM t WHERE id > ? ORDER BY id ASC LIMIT 1。
注意：这里 ORDER BY id ASC 不能省，哪怕 id 是主键，MySQL 也不保证无序 WHERE 下的返回顺序；PostgreSQL 更严格，不加 ORDER BY 直接报错。
典型翻页场景中，用户当前看到的是 id = 100 的记录，想查“下一页第一条”，就得先拿到 id = 101（假设存在）再查整行。这时候别在应用层算 100 + 1，因为中间可能有删除。
- 用
>+ASC+LIMIT 1组合，才是安全的“下一个”语义 - 如果没下一条，子查询返回
NULL，主查询WHERE id = (subquery)就查不到结果，需在应用层判断 - 避免写成
SELECT * FROM t WHERE id > 100 LIMIT 1—— 缺少ORDER BY，结果不可靠
一次查出上一条、当前、下一条的 id 怎么写
用 UNION ALL 拼三个子查询最清晰，比写复杂 JOIN 或多重嵌套可读性强、执行计划也更可控。
示例（查 id = 100 周边）：
SELECT 'prev' AS pos, id FROM t WHERE id 100 ORDER BY id ASC LIMIT 1
这样返回三行，带标记，应用层好区分。别用单条语句里塞三个相关子查询（比如 SELECT (sub1), (sub2), (sub3)），MySQL 5.7 及以前会为每个子查询重跑全表扫描，性能爆炸。
-
UNION ALL比UNION快，因为我们不需要去重 - 三个子查询彼此独立，数据库能并行准备（取决于引擎），比串行嵌套快
- 如果某条不存在（比如已是第一条），对应部分就空，整体还是返回 1–3 行，应用层按
pos字段判断即可
为什么不能直接用 OFFSET 和 LIMIT 做上下翻页
因为 OFFSET 在大数据集上越来越慢，尤其是往后翻页时，数据库仍要扫描跳过的所有行。而基于 id 的子查询是索引直达，复杂度始终是 O(log n)。
比如查第 10000 页、每页 20 条，OFFSET 199980 要先定位到第 199981 行，即使有索引，B+ 树也要从根一路往下找，还可能涉及大量页面读取；而 WHERE id > 199980 ORDER BY id LIMIT 1 直接走 id 索引的范围扫描，快一个数量级。
-
OFFSET翻页适用于小数据、原型阶段；上线后只要有百万级数据，就必须切到游标式分页（即用id或时间戳做边界） - 子查询方式要求
id字段有索引，且查询条件必须命中该索引，否则退化成全表扫描 - 如果业务允许，把“上一条/下一条”做成两个独立接口，比一次查三行更轻量、缓存更友好
实际用的时候，最容易被忽略的是：子查询里漏掉 ORDER BY，或者误以为 id 连续就能用加减法代替查询。这两点在线上一出问题，就是翻页错乱、数据跳变，而且很难复现。
