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

这样就会涉及到几个改造：

1. 应用自身对这些数据的查询、写入都要改为调用一个独立的 Dubbo 服务，由这个服务对迁移的表进行操作。
2. 暂时不做数据迁移，所以查询时也得按照分表那样做一个兼容，如果查询老数据就要在当前库查询，新数据就要调用 Dubbo 接口进行查询。
3. 对这些表的一些关联查询也得改造为查询 Dubbo 接口，在内存中进行拼接即可。
4. 如果数据量确实很大，也可将同步的 Dubbo 接口换为写入消息队列来提高吞吐量。

目前我们将这类数据量巨大但对业务不太影响的表单独迁到一个库后，数据库的整体 IO 下降明显，业务也恢复正常。

总结

最后我们还需要做一步历史数据归档的操作，将 N 个月之前的数据要定期迁移到 HBASE 之类存储，保证 MySQL 中的数据一直保持在一个可接受的范围。

而归档数据的查询便依赖于大数据提供服务。

本次分库分表是一次非常难得的实践操作，网上大部分的资料都是在汽车出厂前就换好了轮胎。

而我们大部分碰到的场景都是要对高速路上跑着的车子换胎，一不小心就“车毁人亡”。

【编辑推荐】

1. 超详细的数据库主机及数据库日志收集总结
2. 值得推荐的四款优秀图形数据库
3. 后端程序员必备：MySQL数据库相关流程图/原理图
4. 8月数据库排行：Oracle 节节攀升，PG 和 MongoDB 分数再现下跌
5. 面试官：在使用MySQL数据库时，遇到重复数据怎么处理？

（编辑：应用网_丽江站长网）

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