我个人觉得，这些数据不是核心数据，是允许一定量的误差的，所以可以放在缓存里，没必要单独作为字段。缓存时时更新，当检测到缓存为空的时候就去数一次，然后回写到缓存

我的User系统分成了三级：
user表存储用户的基本信息，包括登录、状态、姓名、邮件、手机、积分、余额
user_info表存储用户的扩展信息，包括联系方式、个人描述，头像、等不会立即使用的信息
user_info表中有个TEXT类型的settings字段，存储各种扩展状态（序列化后的数组）

仅供参考。
林外@gaosboy 说的有道理。

专门分一个表比较好， 一个原因是@gaosboy说的，这些不是核心数据。另外一个原因是我们一般要把不易改变的数据（这个例子里面就是核心数据）和易变数据（这个例子里面就是这些登录次数之类的）分开。因为对于query cache来说只要表里面的一条数据发生改变，那么表的相关query cache就被清掉。所以把易变数据和不易变的数据分开可以更加有效的利用 query cache。

适合需求的设计就是好设计，不必过早优化，怎么设计user表也是一样。怎么设计，取决于系统的需求、用的软件和架构。
在数据量不大、更新不频繁的情况下，何不就简放在一个表中，等一段时间用户数量级变化后，原始架构是否还能支撑新需求不可获知，再作优化或重构也行。
如果数据量大时，也还是要看需求对数据实时性和准确性要求高不高，都会有不同的设计。

首先要考虑性能瓶颈在哪里。如果你的查询压力很大，而且分开以后会导致需要join才能得到数据，那么据不应该分开。
如果不会导致join查询，比较建议你分开。因为MySQL访问是按照页来访问的，分开意味着减少对其他字段的访问。 一个page可以放更多的数据，可以减少io压力和增加内存利用率。