-
我的列表分页接口翻到前几页飞快、翻到几十万页却越来越慢直到超时,我盯着那条带巨大 OFFSET 的 SQL 排查了大半天才搞懂深分页的真相
我的列表接口用经典 LIMIT offset,size 分页,前几页几十毫秒、翻到第 1000 页 200 毫秒、翻到几十万页(LIMIT 1000000,20)要好几秒甚至超时。明明每页都只取 20 条,凭什么越翻越慢?EXPLAIN 后才懂:LIMIT offset,size 不是"直接跳到第 offset 行",而是从头扫描出 offset+size 行、把前 offse…- 0
- 0
-
翻页越翻越慢直到超时:深分页避坑复盘
这个性能问题有一个特别有意思的特征:它越往后越慢。我们一个数据列表接口支持翻页查看,前几页快得飞起几十毫秒就返回,可有用户反馈翻到很后面的页几百页上千页时接口越来越慢,翻到几千页时甚至直接超时了。我一开始很困惑:同样是查20条数据啊,第1页查20条很快第5000页也是查20条,凭什么就慢了几百倍甚至超时?排查之后真相指向一个几乎人人都在用却很少有人深究其代价的写法——用 LIMIT offset,…- 0
- 0
-
翻到后面页就超时:MySQL 深分页避坑复盘
有个数据列表接口支持翻页,用的是最朴素的写法 SELECT * FROM orders ORDER BY id LIMIT ?, ?,前端传页码后端算 offset,刚上线数据量小翻哪页都飞快。可随着数据涨到几百万行,用户翻到后面页时接口慢得离谱——翻第一页几毫秒,翻到第一万页要几秒,翻到几十万页直接超时,诡异的是每页明明都只取 20 条数据凭什么翻到后面就这么慢?EXPLAIN 后真相清楚了:很…- 0
- 0
游标分页
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×