最近在做一个项目，其需求很普通，很常见，就是在常规业务中统计相应的数据，产生统计分析值。这个需求之所以复杂，主要是其中统计所需要的数据都是来源于较大表（单表一年数量级在4亿上）。直接使用SQL查询并完成基础数据统计，需要关联两张这样的达表查询，这样的数据量使用这种方法绝对是会被DBA提刀砍的（我们的DBA团队也是行业里算得上数的，砍人这个方面个个也都是熟手），这个已经不是通过SQL优化或是索引能完成的事情，单独看这一个SQL，IO就能达到2400，在万级以上的用户时，稍微有点并发数据请求，就能可能导致数据库高load，DB处理不过来。
在分析方案前，先大致介绍下这个需求，列表展现在一些统计分析数据，这些数据来源于两张超级大表，不是简单的关联，对原数据需要一些四则运算，由于我们使用了一些UI组建，在处理分页显示时，也需要单独的一个SQL处理总数据量，运气不巧，这个统计使用的表也是千万级的。完成一次这个页面数据显示，所请求的SQL可以达到一万的IO。最重要的是，商业需求：这些数据显示需要实时！
对于这个问题解决方案，我们分析了如下几套：
1、按需查询 。在列表页面上添加一个刷新功能按钮，最终用户可以通过点击这个按钮，实时统计其自己的最新数据，在后台完成这些数据的持久化，在其下次正常请求列表数据时，显示上次更新后的数据。这样一定程度上增加用户的使用成本，避免用户由于无意识的请求最新数据降低DB的压力。用户按需获取自己所关心的数据状况，间接支持实时显示数据的要求，对于较高并发所引起的DB压力，可以通过性能测试，找到并发压力数，通过机制控制同时请求数，对于多余当前请求量时，屏蔽这次请求，并给予用户提示。
2、使用Job 。使用任务机制，在晚间定时计算用户数据，并将其持久化，这样用户在查询时就会有近乎一天的数据延时。这个方案对整个DB压力不大，但是不能满足本次商业需求，在使用时这个方案时，如果用户量较大，每天更新所有用户数据没有必要，可以根据日志机制，记录当日有业务发生的用户ID，然后定时执行时按这个ID表来更新，这样进一步降级计算压力。
3、业务入侵 。就是在做相关单据业务时，完成新数据对统计数据的变更，这个方案也要使用数据记录表，持久化记录用户所需要查询的数据。这个方案需要注意这个数据更新操作不应该对原业务流程产生影响，不能放入当前业务流程事务中处理。由于当日执行数据的不可靠性，必须有一种保证机制，来消除异常计算数据的差异。如果在后期做如此修改，对原业务代码有较多的改动，而且这种其他业务入侵可能导致的耦合度需要控制。
对于商业需求的满足，我们最终采用了第三种方案，前面两种方案并非是不可行的，主要要确定当前的状态，如果数据量不大，或是并发不大的情况下，前两种应该是工作量最小而且能满足期许的办法。我们在基于第三种方案开发时，综合商业需求分析，对其他可能以及潜在的统计需求进行了分析，在对业务变动时，仅仅统计特定的变动数据，产生新的源数据表，然后其他分析业务从这张表中获取数据，将分析计算压力分散到各个业务逻辑。对于源数据的准确性维护，也采用常用的Job机制，每日定时去重新计算。