-
列表页前几页飞快、翻到几千页后接口直接超时,我用 LIMIT 一百万逗号二十去查那一页才发现数据库默默扫描并丢弃了前一百万行:一次深度分页 LIMIT offset 性能塌陷的深度复盘
我做了个数据列表页支持翻页,后端分页用最常见的 SELECT * FROM orders ORDER BY id LIMIT offset, size。前几页飞快,可用户翻到很靠后的页(第几千页)接口就慢到超时 500。抓出那条慢 SQL 一看 offset 已到百万级。EXPLAIN 才发现:LIMIT 1000000, 20 不是直接跳到第 1000000 行取 20 条,而是从头扫描并丢弃前…- 2
- 0
-
我的列表接口前几页飞快、翻到几十万页却慢到超时,同样是查 20 条,凭什么越往后越慢,我对着深分页的 LIMIT offset 排查了大半天的复盘
做了个支持翻页的列表接口,用经典的 LIMIT offset, size 分页,上线一切正常,直到有用户(或爬虫)翻到很后面的页码,监控告警炸了:同样每页查 20 条,第 1 页几毫秒、翻到几十万页却要好几秒甚至超时。一脸问号——不都查 20 条吗凭什么后面慢成这样?排查大半天才理解深分页那个致命陷阱:LIMIT 1000000, 20 不是"直接跳到第100万行取20条",而…- 0
- 0
-
我的列表分页接口翻到前几页飞快、翻到几十万页却越来越慢直到超时,我盯着那条带巨大 OFFSET 的 SQL 排查了大半天才搞懂深分页的真相
我的列表接口用经典 LIMIT offset,size 分页,前几页几十毫秒、翻到第 1000 页 200 毫秒、翻到几十万页(LIMIT 1000000,20)要好几秒甚至超时。明明每页都只取 20 条,凭什么越翻越慢?EXPLAIN 后才懂:LIMIT offset,size 不是"直接跳到第 offset 行",而是从头扫描出 offset+size 行、把前 offse…- 0
- 0
分页优化
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×