也许是东半球直接底气的分库分表实践了

至此整个分表操作完成。

业务兼容

同时分表之后还需要兼容其他业务;比如原有的报表业务、分页查询等，现在来看看我们是如何处理的。

报表

首先是报表，没分表之前之间查询一张表就搞定了，现在不同，由一张表变为 N 张表。

所以原有的查询要改为遍历所有的分表，考虑到性能可以利用多线程并发查询分表数据然后汇总。

不过只依靠 Java 来对这么大量的数据做统计分析还是不现实，刚开始可以应付过去，后续还得用上大数据平台来处理。

查询

再一个是查询，原有的分页查询肯定是不能用了，毕竟对上亿的数据分页其实没什么意义。

只能提供通过分表字段的查询，比如是按照订单 ID 分表，那查询条件就得带上这个字段，不然就会涉及到遍历所有表。

这也是所有分表之后都会遇到的一个问题，除非不用 MySQL 这类关系型数据库。

分库

分表完成后可以解决单表的压力，但数据库本身的压力却没有下降。

我们在完成分表之后的一个月内又由于数据库里“其他表”的写入导致整个数据库 IO 增加，而且这些“其他表”还和业务关系不大。

也就是说一些可有可无的数据导致了整体业务受影响，这是非常不划算的事情。

于是我们便把这几张表单独移到一个新的数据库中，完全和现有的业务隔离开来。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!