1
nolo 2022-03-14 13:34:57 +08:00
bitmap 索引试试?
|
2
wd 2022-03-14 13:48:59 +08:00 via iPhone 7
直接看最后,这文章是搞笑的...
|
3
cslive 2022-03-14 13:53:27 +08:00
同楼上,拉到最后看完你文章有惊喜
|
5
dzdh 2022-03-14 14:04:14 +08:00
没有。这不是 Pgsql 的问题。所有 SQL 数据库都存在分页到后面越来越慢问题。
海量数据查询、排序、分页。请直接上搜索引擎。 |
6
3dwelcome 2022-03-14 14:18:34 +08:00
我竟然信了。。一直看到了文章最后,差点晕过去。
话说大数据分页始终是个比较麻烦的问题,不同排序和字段过滤,会导致完全不同的分页结果,连缓存都不太好做。 |
7
luckyrayyy 2022-03-14 14:28:45 +08:00
哈哈哈哈笑死
|
9
oneisall8955 2022-03-14 15:19:33 +08:00
最终,发现问题的根源是索引损坏,导致分页时排序太慢。。。。。。。。。
|
10
hidemyself 2022-03-14 15:20:36 +08:00
答案是没有,要么上 ES 这种
|
11
Vegetable 2022-03-14 15:26:25 +08:00
根据我对很多“大厂”项目的观察,真的没有完美的分页方案。
|
12
leoskey 2022-03-14 15:27:12 +08:00
上 ES 后又发生新的问题🐕 https://www.v2ex.com/t/840193
|
13
sfqtsh 2022-03-14 15:39:44 +08:00 via Android
用游标呢
|
16
hope4tomorrow 2022-03-14 16:00:58 +08:00
用 mysql 也出过类似的问题,ID 主键索引不连续了,200w 数据分页一次要 2s ,在 leader 指导下直接对 ID 建索引,再分页查询立马起作用🥱
|
17
MoYi123 2022-03-14 16:17:26 +08:00 1
@hope4tomorrow 不是很懂, 为什么要给主键再建一次索引?
|
18
westoy 2022-03-14 16:23:45 +08:00
淘系你订单多的话, 中间也慢的, 而且经常会排序出错, 缓存上半天不变
京东我怀疑会定时腾冷热数据, 它家是真的存在不定时丢单的 这两家我估计已经接近消费领域性能和误差折中的天花板了 |
20
so1n 2022-03-14 16:40:14 +08:00
数据库本身就不擅长做分页的
|
21
kaifeiji OP @sfqtsh 明白你的意思了,MOVE absolute 确实可以跳转到指定页,但它的实现和性能与 limit-offset 是相同的,所以耗时也是线性增长
|
22
hooopo 2022-03-14 16:44:24 +08:00
还是有的
|
23
3dwelcome 2022-03-14 16:57:24 +08:00
@kaifeiji "但它的实现和性能与 limit-offset 是相同的,所以耗时也是线性增长"
基本上好一点的网站,翻页都是有限制的,用户也不可能无限翻下去。无限翻页就是个伪需求。 头 100 页内存缓存一下,基本上能应付 95%的情况。剩下的 5%,也不会强制要求高性能。 坚持说数据库 limit-offset 性能有问题的,不是傻就是坏。 |
24
9c04C5dO01Sw5DNL 2022-03-14 17:02:23 +08:00
es 也没有完美分页
|
26
Oktfolio 2022-03-14 19:32:33 +08:00
搜索引擎一定条数之后不是也只能游标分页吗?
|
27
felixcode 2022-03-14 19:45:27 +08:00 via Android
文章的最后
========== P.S 最终,发现问题的根源是索引损坏,导致分页时排序太慢。 修复索引后,耗时 1 秒以内——千万级的数据分页,LIMIT-OFFSET 还是 HOLD 住的。 也就是说,我前边整的活儿算是白折腾了。 =========== |
28
Sasasu 2022-03-14 20:01:08 +08:00
有些奇葩 ORM 发出来的查询长这样:
select count(*), * from (<query>) limit 20 这种人现在的计算机科学还满足不了他 |
30
ClarkAbe 2022-03-14 21:26:39 +08:00 via Android
mysql limit page 现在差不多 300 万订单数据了还是很快的啊,毫秒级响应.......
|
31
hope4tomorrow 2022-03-14 23:07:30 +08:00
@MoYi123 因为原有的主键索引失效了,失效原因是,那个表是开发环境的日志表,组里有同学操作过,删除了一些数据,导致索引也失效了,所以再建一次索引,leader 当时的描述是,建一个二级索引
|
32
ipwx 2022-03-15 00:11:42 +08:00
ES 的底层是 Lucence ,LUCENCE 在我当年学习的时候,分页原理应该是直接用关键词抽出来一些倒排索引,然后用优先队列对倒排索引进行合并,上面的结果打分以后用一个大小为 K * page_size 的堆保存最好的前 K 页结果然后返回第 K 页的内容。
|
34
encro 2022-03-15 09:05:20 +08:00
分页关键点:
1 ,数据量大情况下不要 count ; 2 ,复杂查询用 es 之类; 3 ,索引排序; 4 ,组合索引; 5 ,索引类别; 6 ,explain ; |
35
Geekerstar 2022-03-15 13:55:49 +08:00
@leoskey 哈哈哈,被老哥鞭尸了
|
36
Sasasu 2022-03-15 14:26:20 +08:00
@hooopo 随便一个搜索引擎搜 '分页组件是基于 Mybatis 的,它会在你写的 SQL 脚本外面再套一层 SELECT COUNT(*) ROWNUM_ FROM (….) 计算总记录数,同时有另一个嵌套 SELECT * FROM(…) WHERE ROWNUM > 10 AND RONNUM < 10 * 2 这种方式生成分页信息'
|
40
KouShuiYu 2022-03-30 17:08:18 +08:00
limit-offset 还有一个坑必须加上 order 且排序要唯一,不然查出来的顺序会随着 limit-offset 参数不同而变化🐶
|
41
liaohongxing 2022-04-05 09:34:55 +08:00
tidb 有个 tiflash 组件, tiflash 据说魔改的 clickhouse, 基于列存储, 实测 count 也快,分页也快 ,最完美的应该就是基于列存储,根据 sql 自动选择, 这样 where x1= ? and x2= ? ,根据列查
|