日志是写数据库好还是文件好，以及日志策略

先来看看大佬的一句话：离开需求谈技术都是扯淡 

主要是看你的日志是为了只做一个存储归档，还是要把数据对统计与分析

如果只是为了存储一下日志，不做统计与分析的话，存储文件是个不错的选择，和数据库独立

如果要把数据做统计与分析，还是存储数据库吧，因为数据库对后面的数据统计分析有很大的帮助

当然可以把这两种方案结合起来使用

因为日志其实也可以分为很多种类型，比如系统日志给开发人员看的，交易记录等日志需要各种报表统计给boss,管理层看

所以还是那句经典的话：离开需求谈技术都是扯淡 

下面看看大佬的分析

再从需求膨胀这个角度上讲，统计在复杂一点儿的系统中花样儿很多。写文件对后边归档，还真没sql方便。所以。数据库是最好的选择。

为了解决性能问题，一般统计是要做累计表的。
其本都不会直接从原始数据表去统计。 

更好的做法还会把这部分统计分离到其它数据库，防止对主库有影响。

所以，又回到原点儿了，选用什么技术，还是取决于你自己对要做的功能需求的理解到哪种程度。
比如，你感觉他撑死用户量也过不了万。
那怎么玩都可以。
你觉得他系统看起来苗头很不错,牛B完了，那你就得考虑长远一点点儿，搞个累计表。

如果你觉得，操，这东西我觉得要上天，那你就在开始的时候把分库分表考虑进去。

什么是累计表

有的统计会要求统计，按周，按月，按年。

意思是，你会在第周的时候就把累记到周表里面，然后到了月底的时候只需要查询周的，到了年底的时候，会去查询月的。

你按年统计的时候，只需要统计月表里面12条记录。

相当于就是：一个详情表，一个周表，一个月表等

相当于先把数据整合好，查询的时候就非常方便的

跟分表其实是不同概念，这个累计也是要根据业务具体需求来的。  但，方法类似，让表变小一些。 

这个相当于是统计表，分表是把明细表分成很多小表。