awstats在进行日志统计时，
命令行统计增加： -databasebreak=day
报表输出时增加： &databasebreak=day&day=DD
即可按天进行统计, 解决按月统计，归档数据过大导致统计过慢/失败的问题。
问题：
很多网站在流量从10万级增加到百万级以后就放弃了awstats作为统计，具体表现就是到月底的时候，统计数据会运行1天都运行不完。于是就改为webalizer或者analog了。其实这并非awstats统计效率不高：awstats很多丰富的统计指标：蜘蛛识别 浏览器识别，文件类型统计等，都是比Webalizer丰富的，Webalizer要实现类似的统计力度也会出现性能问题。
原因分析：
性能的瓶颈在哪里呢：awstats统计缺省时按月统计，到月底时候记住的头20多天的历史IP等累计统计指标，会使得DUMP数据文件变得很大（数百M），而awstats运行时，需要的内存量是dump数据文件的3－4倍。当这个monthly积累的数据导致awstats统计脚本载入内存的数据量过大，用到系统文件交换做内存的时候日志统计效率就会降低了（处理速度会低2-3个数量级），于是出现了运行一天都统计不完前一天日志的现象。
解决：
AWStats丰富的统计指标还是很有用的，而一个网站已经达到日千万级的访问请求，按天的详细的数据统计也是必须的了。所以：索性牺牲一下按月的独立IP统计，将日志改成按天统计，如果需要按月的汇总，可以利用awstats的dump数据成为一个中间数据源汇总统计。
其他问题：
1 按天的报表浏览：用Calendar.php做个日历浏览界面；
按天统计后，awstats的输出文件会变成awstatsMMYYYYDD.confname.txt 每天一个统计文件，而报表的输出需要增加 &databasebreak=day&day=DD 来指定某一天的数据。增加了日期后，awstats的报表输出有些不方便，awstats本身没有提供按日的浏览，可以自己做个日历前端，方便awstats的报表浏览。
2 日志数据源：最好是压缩的，因为日志上2G以后，文件系统出问题的可能性大。尽量还是压缩日志后，通过zcat管道给awstats进行统计；
类似的思路：
1 如果 databasebreak=day 仍然无法解决问题， 排除掉次要统计指标：过滤掉图片 js css等文件的请求日志；
2 如果仍然没有办法解决问题： 设置为小时级别截断 databasebreak=hour 然后用每天的同一个小时（比如：下午5点－6点）做为1天的抽样，进行每天的数据跟踪；
总之：为了统计精度/完整性牺牲重要的统计统计指标是不值得的。当流量提高到百万级别，即使损失了n%的精度，对于做出结论已经足够了。而且利用awstats 的dump data作为中间处理结果，进行数据挖掘也是很方便的（大部分是CSV，分项的很容易用grep截取分离出来）。