速度慢不是因为几百G,而是因为行数多。根本原因是即使有索引,在如此多的数据量下,单服务器的索引本身访问已经很耗时了。 建议: 1、首先商议并固化查询条件。这个和具体产品有关系。比如,按照时间、账户、类别之类的关键字查询。 2、用每次客户都会指定的那些字段进行组合生成分区规则,用于单台服务器上的分区。 3、如果有独立子数据集合(如大的地理区域之类,访问A城市的数据,就很少会访问B,如同城的消费之类的情况),就太好了,直接怼服务器。 4、买几块固态SSD建立盘阵,索引就放在SSD上。毕竟,只要有银子,那都不是事。
更别说分到多台服务器来分散查询了
至于查询效率,不管分区还是分表,如果你始终要从所有表中去找出数据,那么怎么分帮助也不大(除非分散到各服务器,然后程序上分别查询之后合并) 另外,如果你的查询只涉及部分的分区(或分表),但如果均未从你的查询写法或条件上预判出涉及的分区或分表,那就也意味着要查所有数据去找满足条件的了,这种情况分区和分表也没意义
查询是实时的业务,要增加用户体验,主要是要求响应时间要及时。
@發糞塗牆 很久没有上论坛了啊
总共数据有多少行?另外相关的查询也可以发来看看 关于方案1 ,在不断增大期间还是会有撑不住的时候的问题。 可以建立一个归档表,定期把不用的数据(比如三年以前的数据)放到归档表里面。 关于方案2,如果你分表之后还是需要把所有数据查询出来的话,那么性能的提升也不会很明显。这种情况,你可以选择读写分离架构。报表允许执行时间长一点,但是不会 影响OLTP的业务
27,579
社区成员
68,558
社区内容
加载中
试试用AI创作助手写篇文章吧