我觉得这是一件很有学问的事，然而这个学问我并没有。不过我们可以一起学习，这篇文章我将会以 分享我淘到的帖子的方式和大家一起学习。另外我会提出我遇到的问题，我都列出来，我们一起寻找解决方案。如果项目能够上线，我也愿意分享我最终的解决方案。
# # 展望
为什么说这是一件有学问的事。对一个公司来说，账不平，都是自己承担的，百花花的银子，能没有学问吗？
不想卖高价的猪就不是一个好猪。我们在设计系统的时候，永远要站在架构的角度，拿着望远镜看的眼光才行。比方说我在做的对账系统，虽然是在初期，不太会有太多的用户进来，不太会有太多的订单量，明明连上完的订单量都没有，但是我们却要考虑千万级别的设计。需求往往就是这样，不然做技术的哪儿来的好玩。
# # 问题清单
1. 千万级别，我们应该选用哪些技术，用什么技术架构号一点。
2. 读数据分页的问题。别说千万级别了，就是十万级别的数据，都是一个问题。
3. 处理数据 OOM 的问题。
4. 对账流程应该怎么写？如何保证一个全覆盖的对账。
# # 比较不错的帖子
如何完成日千万级别以上的订单对账（一）
如何完成日千万级别以上的订单对账（二）
如何优化Mysql千万级快速分页,limit优化快速分页,MySQL处理千万级数据查询的优化方案！
如果不懂什么是对账结账，看看 「财务对账」
# # 我自己的不现实的想法
1. 情况是这样的，我的需求只有对两张表的的某个字段，就是订单号。 A表出现了，看B表出现没，如果没出现就记异常，反之亦然。如果没有都出现了，则需要对比出现的次数。看出现的次数时候一致。因为只有一个字段，varchar 10 ，我想的是，都查出来以后放在 set 中去。具体想法我贴一个手写的图：
为什么说不现实呢，从数据库一下子取这么多数据，不合适。 都放在内存中不合适。
目前的业务量没有那么大，我把从A表B 表取出来的一个字段分别放在 两个 HashMap 中去，我计算的占用的内存，大概占用了1.5 个G。 这让我觉得一下子去处理可行，因为减少了很多的麻烦。
推荐的处理方案是分页去处理。这里我今天先不写。最终敲定再说。
# # 我的感悟
站在架构的角度上，从数据库的设计上就应该去考虑这件事。
另外，对账不是一件小事，我觉得应该专门的去设计一下，架构一下，去应对各个维度的对账。
