MySQL 大表排序有什么好的方案?只能上 Mongo?

1

MongoDB 也不是魔法啊大家都是建索引,只能是你在数据结构上做一些优化单独加一个排序字段

2

@nomagick 加一个排序字段?每次插入数据的时候都要计算序号?

3

@CooperB 按值排序啊,你直接定期把索引项计算出来存着

4

不得不再推一波 manticosearch 、openobserve.ai 、PostgreSQL

5

@nomagick 定期索引?那不是有延时?

6

数量级是多少?

7

@CooperB 要不然怎办,就是把数据库的实时计算转成异步,拿到应用节点来算,你可以每次改数据的时候维护一下这个排序字段,查询的时候直接从索引出尽量少占用数据库的 CPU

8

能不能把多个字段拼成一个字段然后进行排序。如果可以的话新增一个排序字段,保存聚合后的数据,插入时给默认值。历史数据另行处理。

9

真有几组组合就不能建多个组合索引?底层数据算法大家都一样的换个数据库有什么用,搞得象别人就有独占魔法一样

10

这其实是一个业务问题,用技术的手段来解决也只会是短暂的。
一次多筛选条件的实时查询,使用者的角度看,他能关注的数据和数量范围是有限的。
所以一般数据密集场景,要么用时间等限制过滤数据的总量,要么牺牲实时性引入外部组件等等。
回到这个问题的一些可能的解决方案:
1. 二/多次过滤:设定几个索引排序优化最明显的主键,这些作为一次过滤/排序的结果,再用这个结果做二次排序
2. 根据数据量,引入统计分析能力好的中间件,像 @dzdh 讲的这些

11

什么算法也不能违背物理学...

12

可以使用下 ADB 。

13

多大,1kw 的数据表,只要回表次数不多,查询还是很快的,50ms 以内没问题。

14

提的问题都不是很清楚,
第一:什么业务类型 ,
第二:估计多大数据量,
第三:业务没办法优化?为什么没办法优化?业务有什么限制、规则?
对业务你做过哪些优化,对 MySQL 、SQL 、硬件等做过哪些优化。

要不然就是一般优化方法:数据能不能分表、存到 NoSQL 类型数据库,ES 、ClickHouse 等、或者大数据计算,Flink 、预先计算 ,。。。

15

大表的具体信息呢,单表多少数据?有多少字段?查询条件是怎样的?目前查询效率是多少?如果没有这些信息的话不太好给出合理的建议。
不过既然考虑更换数据库的话,Clickhouse 可以试一下,我们就是从 MySQL 迁移部分业务到 ClickHouse 了,目前数据量最多的项目 单机单表 过百亿是有的,查询效果还能接受,而且 Clickhouse 压缩率很高 磁盘体积占用减了不少

16

@dzdh #4 manticosearch 理解,pg 也可以么?

17

这不就是典型的列式存储的应用吗, 上 clickhouse + CDC 呗

18

Mongodb 也不是魔法啊。 还得看:
1.单表多少数据
2.列的数量
3.需要排序的字段都是什么类型
4.查询的 SQL 能不能再进行优化
然后从业务方式能不能处理。不能处理。看数据能不能冷热处理一下。都不行,在考虑用其他类型的数据库呗

19

@dddd1919 #16 tsvector 可以自己拼结构。加上索引一样的。千万级不是啥问题。