-
一个用 LIMIT offset 做分页的接口,翻到第几万页时一条查询要跑十几秒,把数据库拖垮:一次深分页性能的深度复盘与游标分页正解
列表接口用最常规的 LIMIT offset 分页,前几页飞快,可爬虫脚本一页页翻到第 5 万页时,同样查 20 条却要十几秒、数据库 CPU 打满。根因是 LIMIT 1000000,20 并不是直接跳到第 100 万行,而是从头扫描出前 1000020 行、丢弃前 100 万行只返回 20 行,代价随 offset 线性增长,SELECT * 还要百万次回表。本文讲透 LIMIT offset…- 0
- 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
-
翻页越翻越慢直到超时:深分页避坑复盘
这个性能问题有一个特别有意思的特征:它越往后越慢。我们一个数据列表接口支持翻页查看,前几页快得飞起几十毫秒就返回,可有用户反馈翻到很后面的页几百页上千页时接口越来越慢,翻到几千页时甚至直接超时了。我一开始很困惑:同样是查20条数据啊,第1页查20条很快第5000页也是查20条,凭什么就慢了几百倍甚至超时?排查之后真相指向一个几乎人人都在用却很少有人深究其代价的写法——用 LIMIT offset,…- 0
- 0
-
翻到后面页就超时:MySQL 深分页避坑复盘
有个数据列表接口支持翻页,用的是最朴素的写法 SELECT * FROM orders ORDER BY id LIMIT ?, ?,前端传页码后端算 offset,刚上线数据量小翻哪页都飞快。可随着数据涨到几百万行,用户翻到后面页时接口慢得离谱——翻第一页几毫秒,翻到第一万页要几秒,翻到几十万页直接超时,诡异的是每页明明都只取 20 条数据凭什么翻到后面就这么慢?EXPLAIN 后真相清楚了:很…- 4
- 0
-
MySQL 慢查询从定位到根治:索引失效、深分页、长事务的排查与优化清单
一套跑了四五年、订单表从几十万行涨到三千多万行的分析库,一条 WHERE DATE(created_at)=CURDATE() 的汇总查询因为在索引列上套了函数而退化成全表扫描,单条 SQL 从设计期的几毫秒涨到线上 18 秒,高并发下迅速占满连接池让整块经营看板瘫痪。这篇不写成「几个人熬了多少天打了多少仗」的流水账,而是整理成一份能直接照着查的慢查询治理清单:先用慢查询日志(long_query…- 0
- 0
-
翻到第十万页接口卡 5 秒:一次 MySQL 深分页优化的复盘
运营后台两千万行的订单列表,前几页飞快,翻到几万页接口卡五六秒甚至超时。根子是 LIMIT offset 要扫描并丢弃 offset 行。几天把深分页彻底重构:offset 慢的本质、覆盖索引+延迟关联、游标分页、复合游标、count 优化、以及用产品设计把深翻页场景设计掉。- 6
- 0
深分页
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×