避坑指南：Doris自增列在分页查询中的5个常见错误用法

最新推荐文章于 2026-05-17 16:31:09 发布

原创

最新推荐文章于 2026-05-17 16:31:09 发布 · 653 阅读

避坑指南：Doris自增列在分页查询中的5个常见错误用法

最近在几个数据中台项目里，我频繁遇到团队在使用Doris的自增列（AUTO_INCREMENT）进行分页查询时踩坑。表面上看，这个功能简单明了——自动生成唯一ID，用来做分页游标再合适不过了。但实际用起来，从性能断崖式下跌到数据一致性出问题，各种“坑”层出不穷。很多开发者，尤其是从传统单机数据库转过来的朋友，容易把MySQL里那套自增ID的使用经验直接套在Doris上，结果往往事与愿违。

这篇文章，我就结合自己最近趟过的雷、修过的线上问题，聊聊在Doris里用自增列做分页时，最容易犯的五个错误。我会用具体的错误案例和可执行的正确方案做对比，目标很明确：帮你避开这些陷阱，设计出既高效又稳定的分页查询方案。无论你是刚开始接触Doris的业务开发，还是正在优化现有数据服务的工程师，相信这些实战经验都能派上用场。

1. 误区一：将自增列直接等同于严格连续的时间序标识

这是最普遍也最危险的误解。很多开发者下意识地认为，自增列生成的值一定是严格连续、单调递增的，并且后插入的数据其自增ID一定大于先插入的数据。基于这个假设，他们可能会写出这样的分页逻辑：

-- 假设这是获取下一页数据的逻辑（错误示范）
SELECT * FROM order_table
WHERE auto_id > #{last_max_id} -- 假设上一页最后一条ID是100
ORDER BY auto_id
LIMIT 20;

这个逻辑在MySQL的InnoDB下可能工作良好，但在Doris中，自增列并不保证严格的连续性和时间顺序。官方文档明确提到，由于分布式系统下的性能优化（例如后端节点BE预分配ID块），自增列的值可能出现间隙（Gaps），并且不保证后续写入的ID一定大于早期写入的ID。

为什么？ Doris作为分布式MPP数据库，为了在高并发写入时避免全局锁成为瓶颈，采用了分块预分配的机制。每个BE节点会预先申请一个ID范围（比如节点A拿到1-1000，节点B拿到1001-2000）。节点内部消耗这些ID是连续的，但节点间的写入顺序无法严格保证全局递增。此外，如果某个事务回滚，其预分配的ID会被丢弃，从而产生间隙。

带来的分页问题：

数据丢失：如果使用WHERE auto_id > last_max_id，且last_max_id恰好落在一个间隙里（比如实际有ID 99和101，但100被预分配后因事务失败丢弃了），那么ID为101的记录可能不会被查询出来，导致用户看到的数据不连续。
排序错乱：如果依赖ORDER BY auto_id来模拟时间序，可能会出现“后发生的事件ID更小”的情况，导致分页顺序与业务时间逻辑不符。

正确方案：使用“业务时间戳+自增列”组合键 分页游标应该基于一个真正有业务意义且保证（或近似）时序的字段，自增列仅作为辅助去重或二级排序。

-- 创建表时，包含业务时间和自增列
CREATE TABLE `order_table` (
    `order_id` BIGINT NOT NULL,
    `create_time` DATETIME NOT NULL COMMENT '订单创建时间',
    `auto_inc_id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '辅助自增列',
    ... -- 其他字段
) ENGINE=OLAP
DUPLICATE KEY(`order_id`, `create_time`)
DISTRIBUTED BY HASH(`order_id`) BUCKETS 10;

-- 分页查询：以业务时间为主游标，自增列为辅游标
SELECT * FROM order_table
WHERE (create_time > #{last_create_time})
   OR (create_time = #{last_create_time} AND auto_inc_id > #{last_auto_id})
ORDER BY create_time ASC, auto_inc_id ASC
LIMIT 20;