无自然排序数据的SQL分页方案探讨（UUID主键场景）

为什么OFFSET分页性能差 #

用OFFSET n分页时，数据库需要先对全表（或索引）排序，再跳过前n行返回结果。当n很大时，扫描的数据量随偏移量线性增长，性能呈O(n)下降。而UUID本身是随机值，即使有主键索引，索引叶子节点也是离散的，进一步加剧磁盘随机IO开销，导致大偏移量下性能急剧下降。

通用高效方案：基于锚点的范围分页 #

这是替代OFFSET分页的最优方案，和你之前用自增ID的思路一致，所有主流关系型数据库都支持，且性能恒定，不受偏移量影响。

实现方式 #

• 第一页查询：直接取前100条

  SELECT *
  FROM your_table
  ORDER BY uuid
  LIMIT 100;
  

• 后续分页：以上一页返回的最后一条数据的UUID作为锚点，用范围查询定位起始位置

  SELECT *
  FROM your_table
  WHERE uuid > '{last_seen_uuid}'
  ORDER BY uuid
  LIMIT 100;
  

• 反向分页（上一页）：如果需要回退到上一页，用当前页第一条数据的UUID作为锚点，反转排序方向

  SELECT *
  FROM your_table
  WHERE uuid < '{first_seen_uuid_of_current_page}'
  ORDER BY uuid DESC
  LIMIT 100;
  

  拿到结果后在应用层反转顺序，即可得到上一页的正确排序。

核心优势 #

UUID作为主键本身就有唯一索引，WHERE uuid > 'xxx'可以直接利用索引定位到起始位置，不需要扫描前面的所有行，查询性能和偏移量无关，保持恒定。

MariaDB特定优化：使用有序UUID #

如果业务允许修改UUID的存储方式，建议使用有序UUID进一步优化性能：

• MariaDB支持UUID_TO_BIN(uuid, 1)将UUID转换为有序二进制格式（把时间戳部分放在前面），存储时用这个函数生成主键，索引的叶子节点会按时间顺序连续排列，减少磁盘随机IO。
• 示例代码：

  -- 插入数据时生成有序二进制UUID
  INSERT INTO your_table (uuid, column1, column2)
  VALUES (UUID_TO_BIN(UUID(), 1), 'value1', 'value2');
  
  -- 查询时转换回字符串格式（如果需要返回给应用）
  SELECT BIN_TO_UUID(uuid) AS uuid, column1, column2
  FROM your_table
  WHERE uuid > UUID_TO_BIN('{last_seen_uuid}', 1)
  ORDER BY uuid
  LIMIT 100;
  

其他主流数据库的适配方案 #

• MySQL：和MariaDB完全兼容，MySQL 8.0+同样支持UUID_TO_BIN和BIN_TO_UUID函数，范围分页逻辑一致。
• PostgreSQL：原生支持UUID类型，直接使用范围分页即可；也可以通过pgcrypto扩展生成带时间戳的有序UUID（如uuid_generate_v1mc），进一步优化索引性能。

  SELECT *
  FROM your_table
  WHERE uuid > 'last-seen-uuid'
  ORDER BY uuid
  LIMIT 100;
  

• SQL Server：使用UNIQUEIDENTIFIER类型，范围分页用TOP替代LIMIT；也可以用NEWSEQUENTIALID()生成有序的唯一标识符，提升索引效率。

  SELECT TOP 100 *
  FROM your_table
  WHERE uuid > 'last-seen-uuid'
  ORDER BY uuid;
  

注意事项 #

• 范围分页的局限性是无法直接跳转到指定页码（比如直接访问第100页）。如果业务必须支持跳页，且跳页概率极低，可以偶尔使用OFFSET分页；如果跳页需求频繁，需要额外维护分页映射表（比如按时间分块记录每个块的起始UUID），但会增加系统复杂度。
• 必须保证ORDER BY的字段和WHERE条件的字段一致，且有索引覆盖，避免数据库执行额外的排序操作。

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