我要做一个用户积分的模块。
用一个表记录用户积分的增减
每次需要读取用户积分或者判断用户积分够不够时,就用sum来获取。问题来了,随着用户的数据不断类积,增至千万条数据,那sum的效率怎么办呢,每次判断用户积分够不够时,都要sum一下的。如果光用一条记录或者存在用户表中的一个字段里来存储用户的积分余额,似乎又不安全和不准确。或者有其他的方案吗,大神们怎么做的。 

解决方案 »

  1.   

    就是因为有这种【不准确】的可能,所以数据库才需要事务和锁。其实 sum 的行数多了,不准确的可能性更大……
      

  2.   

    这其实就是不同时代,不同层次的区别。如果是30年前,某些人认为什么都能用超级计算机来解决,而且并发量其实很小很小,所以他们会滥用事务、滥用视图。所以你看大的政府机关、垄断行业的软件开发人员,就是养在深宅大院的理论者。实际上在过去20年,对于一般的高并发场景(例如大型百货的前端网络系统),如果业务复杂,也不能随便照搬数据库概念。在业务上一定是有许多环节都是分时处理的。例如许多信息是根据快照来的,绝不是临时统计的!如果是最近3年,你看到电商的巨量扩张,别说什么“去IOE”,就算是随便一个核算环节,都要去平衡想象中的所谓数据跟现实的差别。你设计一个系统时,应该首先在流程上就应该先假设数据快照有差别,然后只是根据现实去缩小差别。绝不是从理论出发去首先全盘否定差别。
      

  3.   

    如果你的出发点就是“一丁点差别都是不允许的”,那么你就上了过去的“唯数据ACID”的套,而不会按照最近5年的高并发系统的思路来设计新系统!