各位好，首先感谢花时间阅读这个问题。
题主目前有个app站点，使用MySQL储存用户数据。目前想增加一个功能：显示用户在过去7天的服务器使用量。目前，数据库中和该功能相关的Columns有两个：
usedTraffic (int) 储存用户已经使用服务量。
allTraffic (int) 储存用户能够使用的服务量上限。
后端会定时更新所有用户的usedTraffic，其字段储存的是用户已使用服务量的总量。
为了实现期望的功能，我目前的想法是：
1.新建一个表，其中一个Column储存用户ID
2.其余7个Columns对应用户过去7天每天的使用量。
3.后端定时更新7个储存数据的Columns。
这样做的问题有：
1.Columns会随时间出现对应的问题：如用户在星期1注册，后端就需要从第一个Column开始读取；如果用户在星期4注册，就要从第四个Column开始读取。
2.数据冗余。目前的站点用户注册量还不算大，但这样设计会出现大量的冗余数据。
这个问题我想了两三天还是没有思绪，还请各位指点迷津，看看是否有更合理的数据库架构，谢谢。
楼上正解，加日期字段处理吧，做日期运算就行了
你的方案扩展性不强，包括横向扩展和纵向扩展。横向扩展已经有同学说的，如果要改成30天就跪了，纵向扩展是如果你要增加一个用户属性呢？比如假设要考虑用户的性别，年龄，喜好，使用服务器时间等。
采用一个表单独记录的方案对大数据量的支持也不够好。一个表的记录数是有限的，现在是7天的数据可能不多，要是未来要做一个月，一年的呢？查询会非常慢。
解决方案：分区表。按照时间分区，一天一个表，每一个表中记录当天用户使用的记录。用脚本控制删除或者打包保存失效的表。每天创建新的表写当天数据进去。类似于服务器日志文件的处理方式。
这种方案扩展性比较好，而且非常适合分布式处理，如MapReduce。数据量大的时候非常合理,而用户行为数据就是典型的大数据场景。Mysql并不是很适合做这种应用，可以参考Hive,或者阿里云的ODPS
假设未来这个功能变成「显示用户在过去30天的服务使用量」，这个表就跪了。
所以每天一个column还不如每天一条数据，记下(uid,日期,当天用量)。这样可以很方便地查出最近n天的用量。
由于目前的需求只需要这个表的数据保存7天，那么写个脚本把超过7天的数据删掉就好。
至于所谓冗余数据，简单算一下，假设一百万用户，总共也不过百兆级别的数据而已。
可以采用mongodb存储