-
我做分页时用创建时间排序、一页页翻,本地看着没问题,可用户反馈翻页时有的数据重复出现、有的却凭空消失,排查半天才发现我排序用的那个列不唯一、值相同的行之间的顺序压根没保证的深度复盘
我做了个列表分页,按创建时间倒序、每页 20 条,ORDER BY create_time DESC LIMIT 20 OFFSET ?,一页页往后翻。本地测试数据不多翻几页都正常我就觉得稳了。可上线后用户反馈诡异的事:翻页时有的数据第 1 页见过第 2 页又冒出来一次(重复),有的明明该在列表里却怎么翻都找不到(遗漏)。我以为是数据有重复或缓存问题,核对数据都好好的,直到发现出问题那批数据有个共…- 4
- 0
-
我的分页接口每次都查一下总共有多少条数据好显示总页数,小表时秒回,数据涨到几千万后这个 COUNT 比查数据本身还慢、直接拖垮了接口的深度复盘
我有个分页列表接口,每次都做两件事:查当前页数据(带 LIMIT)和 SELECT COUNT(*) 查总条数(为了显示共 N 条、共 M 页)。数据量小时一切秒回,可这张表涨到几千万行后接口越来越慢,一查傻眼:慢的不是查当前页(有索引、LIMIT 很快),而是那个看起来最简单的 COUNT(*)——它居然比查数据本身还慢得多、一次要好几秒,拖垮了整个接口。复盘才想明白:InnoDB 不像 MyI…- 0
- 0
-
翻页越翻越慢直到超时:深分页避坑复盘
这个性能问题有一个特别有意思的特征:它越往后越慢。我们一个数据列表接口支持翻页查看,前几页快得飞起几十毫秒就返回,可有用户反馈翻到很后面的页几百页上千页时接口越来越慢,翻到几千页时甚至直接超时了。我一开始很困惑:同样是查20条数据啊,第1页查20条很快第5000页也是查20条,凭什么就慢了几百倍甚至超时?排查之后真相指向一个几乎人人都在用却很少有人深究其代价的写法——用 LIMIT offset,…- 0
- 0
-
翻到后面页就超时:MySQL 深分页避坑复盘
有个数据列表接口支持翻页,用的是最朴素的写法 SELECT * FROM orders ORDER BY id LIMIT ?, ?,前端传页码后端算 offset,刚上线数据量小翻哪页都飞快。可随着数据涨到几百万行,用户翻到后面页时接口慢得离谱——翻第一页几毫秒,翻到第一万页要几秒,翻到几十万页直接超时,诡异的是每页明明都只取 20 条数据凭什么翻到后面就这么慢?EXPLAIN 后真相清楚了:很…- 4
- 0
-
深分页性能优化完全指南:从一次"翻到第 5000 页、查询慢了 100 倍"看懂 OFFSET 陷阱与游标分页
2021 年我做一个后端服务有一大堆列表页要分页订单列表操作日志消息记录。分页这件事我压根没多想。第一版我做得很省事分页不就是 LIMIT 和 OFFSET 前端要第几页我就 OFFSET 页码减一乘每页条数 LIMIT 每页条数跳过前面那些取这一页该取的。本地开发时真不错测试库里就几百条数据我从第一页翻到最后一页每一页都是瞬间出结果顺畅得很。我心里很踏实分页嘛不就是跳过 N 条取 size 条。…- 3
- 0
分页
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×