如何解决Python Django在处理千万级数据量时的分页慢查询问题？-Python教程-PHP中文网

PageNumberPagination在千万级数据上变慢，因其依赖COUNT(*)全表扫描和OFFSET/LIMIT查询，数据库需跳过前N行再取结果，导致响应随页码线性恶化；应改用CursorPagination或键集分页。

如何解决python django在处理千万级数据量时的分页慢查询问题？

为什么 `PageNumberPagination` 在千万级数据上会变慢？

因为 Django 默认分页器依赖 count() 和 OFFSET/LIMIT，而 count(*) 在大表上会触发全表扫描；OFFSET 1000000 要求数据库先跳过前一百万行，再取结果，MySQL/PostgreSQL 都会越往后越慢。

常见现象：第 1 页很快，翻到第 5000 页时响应超 5 秒，甚至触发 DB 连接超时。

PostgreSQL 中 OFFSET 性能随偏移量线性下降，无索引加速时几乎不可用
MySQL 8.0+ 对 LIMIT offset, size 优化有限，尤其配合 ORDER BY 时仍需临时排序
Django 的 PageNumberPagination 每次请求都调用 queryset.count()，哪怕你只想要下一页链接

用游标分页（`CursorPagination`）替代页码分页

游标分页不依赖总数和偏移量，而是基于排序字段的值“锚定”位置，每次只查比上一次最后一条记录更大（或更小）的数据，天然避免 OFFSET。

适用前提：必须有唯一、单调（或严格有序）、可索引的字段作为游标依据，比如 id 或带纳秒精度的 created_at。

在 ViewSet 中替换分页类：pagination_class = CursorPagination
必须显式指定 ordering，例如 ordering = '-id'（升序/降序决定游标方向）
客户端不再传 page=5，而是传 cursor=cD0xMjM0NTY=（Base64 编码的上一页末尾 id）
注意：无法跳转任意页，只能前后翻页；不支持获取总条数 —— 这不是缺陷，是设计取舍

手动实现基于 ID 的键集分页（Keyset Pagination）

比 CursorPagination 更轻量、可控，适合需要精确控制查询逻辑或兼容老客户端的场景。核心是用上一页最后一条的 id 做条件过滤，而不是 OFFSET。

librosa Python 音频与音乐分析库

librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。

下载

示例（获取下一页，按 id 降序）：

last_id = request.query_params.get('last_id')
if last_id:
    queryset = queryset.filter(id__lt=int(last_id))
queryset = queryset.order_by('-id')[:20]

关键点：

id__lt 或 id__gt 必须与 order_by 方向一致，否则漏数据或重复
id 字段必须有索引（Django 默认主键已建 B-tree 索引）
若排序字段可能重复（如 created_at），需组合唯一字段，例如 filter(created_at__lt=last_time) | (created_at=last_time, id__lt=last_id)
首次请求不带 last_id，后续每页返回本页最小（或最大）id 给前端用于下一页