Django中获取当前对象上一条、下一条相邻记录的最优实现方案

1. 原ORM代码对应生成的SQL语句 #

你给出的两句Django ORM代码，底层生成的SQL分别为：

• 下一条记录查询：

SELECT * FROM `mymodel` WHERE `id` > 当前记录ID ORDER BY `id` ASC LIMIT 1;

• 上一条记录查询：

SELECT * FROM `mymodel` WHERE `id` < 当前记录ID ORDER BY `id` DESC LIMIT 1;

注：表名和字段名会根据你实际的Model配置略有调整，核心逻辑一致

2. 原实现是否为最优方案 #

在**按ID升序排序、ID为主键（默认带主键索引）**的常规场景下，这个实现的性能已经非常优秀：查询条件走主键索引，排序直接复用索引的有序性不需要额外计算，LIMIT 1查到匹配记录就直接返回，整个查询是O(1)复杂度的索引检索。
它的不足仅在于两点：

• 需要两次独立的数据库请求，高并发场景下多余的网络交互会带来额外开销
• 如果业务排序规则不是ID，而是其他字段（比如创建时间），没有对应联合索引的情况下会触发全表扫描+文件排序，性能骤降

3. 优化后的SQL写法 #

如果要进一步优化，可以把两次查询合并为一次请求，减少数据库交互开销，优化后的SQL如下：

(SELECT 'previous' AS record_type, * FROM `mymodel` WHERE `id` < 当前记录ID ORDER BY `id` DESC LIMIT 1)
UNION ALL
(SELECT 'next' AS record_type, * FROM `mymodel` WHERE `id` > 当前记录ID ORDER BY `id` ASC LIMIT 1);

如果你的业务是按非主键字段排序，比如按create_time降序排序，一定要给排序字段和ID建联合索引idx_create_time_id(create_time, id)，避免触发文件排序。

4. 逐次加1查询的思路是否可行 #

完全不可行，核心原因有三点：

• 如果ID存在大量断层（比如删除过大量历史记录），你可能需要执行几十甚至上百次查询才能找到下一条存在的记录，数据库交互开销会比原实现高几个数量级
• 如果当前ID和表最大ID差值极大，循环遍历到表末尾会产生大量完全无效的查询请求
• 高并发场景下这种写法会快速占满数据库连接池，直接拖垮整个服务

内容的提问来源于stack exchange，提问作者AlASAD WAIL