大数据量统计

用文件处理会更好，利用数据库显得过于复杂。
用文件处理除了资源占用低效率高的好处外，还可以使用并行计算来提高数据处理速度，甚至完全可以利用awk进行快速处理。
以前做过电信cdr记录处理，都是文件存储然后传输，parsing写入oracle数据库做进一步的其他处理如计费。

MySQL 5.1的分区功能目前还很不完善，要部署的最好还是谨慎一点。

建议很好，强烈建议看看有关数据仓库的东西，直接在业务数据上做统计分析是不现实的，尤其是你这么大的数据量，想任何招都是徒劳。ods，data mart，data warehouse应该是你考虑的方向，也是你的分析系统发展的方向

数据仓库无外乎是上面这些方法的结合，并行计算，ETL等等，现在楼主的情况，要去找非常专业的数据仓库技术做支持，时间是否太久了？

我觉得使用多个文件存储中间数据，java或者C解析文件做汇总，不失为一个好办法，如果存在join的逻辑在里面，会比较麻烦

采用数据库来做，也就是多张小表加并行SQL,最好的多会话的，就是会消耗主机CPU，存储IO等资源，这个可以放在非高峰期来做，持续的时间其实是可以估算的，存储的IO吞吐量可以用表扫描粗略计算出来，走对正确的查询计划就可以了

个人觉得程序能处理的尽量程序做，数据库最好不要封装任何业务逻辑，毕竟他只是个持久层，所scale out比应用层要困难的多

单纯的统计的话，不用楼主说的那么复杂吧，程序里做循环每次读100条进行统计，应该不成问题吧。应该花不了多长时间吧。

纵向：定时或者定量出发子进程处理日志文件，然后清空日志文件，吧分析的中间结果累计到别处，一天下来再作多次中间结果的计算，跟ETL有点类似；
横向：加大计算能力，并行吧。主要是不太清楚你日志文件是什么格式，不知道用map-reduce能不能搞定。即便是在单核机器上，楼主你不会写的单线程处理吧？

- -!  大量数据统计 数据库很不靠谱 hadoop之

强烈建议你抛开数据库,直接走数据文件来解决这个问题.
其实原理也很简单,
第一步,把数据库的内容变成数据文件,按照一定规则切成多个文件,文件名有规律
第二步,写程序一个文件一个文件读取统计,把结果再写回数据库去.

这样做的效果就是利用硬盘空间,而不占用数据库的访问,也不占用过多的内存.
不过DBA就没有用武之地了.

问题就在于1亿多的数据在1张表中
如果按字段分表可能好解决一些 

做直接sql    mysql数据库估计吃不消的 吧？

可以利用游标，将需要的的内容导到文件
再按需字段hash 出不同结果文件

相信1台机子2g的机子也可以处理完任务（只要hash切分的够平衡）

每次读取数据是单线程，处理数据的时候是用多线程处理，等处理完一批再读取数据。
由于项目开发时间非常紧急，hadoop之前没怎么接触过（只是听过），需要加强学习。