在常见的应用系统中，特别是看似较复杂的统计系统中，差之毫厘谬以千里，一不小心一个数据统计错误，特别是给销售提成的统计系统中，一个数字搞错，要不销售找你闹，怎么给我算少了，要不老板打你屁屁，怎么给销售算多了
用好唯一索引，基本成功一大半，可以高枕无忧了
比如我们需要统计每天的活跃用户数，总用户数，每天的总用户数，随着数量的增多，每次我们都去用户表sum,count是比较消耗数据库资源的
有同学会说加一层缓存，那缓存失效的时候还是会去数据sum,有没有更好的办法呢，当然也是缓存，就是把结果数据结果按天存储到MYSQL中持久化，这样每次只需要读取统计结果即可
比如我们需要统计每天的活跃用户数，0点的时候把昨天的数据跑出来
三个字段user_count,day_time,type
分别对应的值为100,20200810,dayuser
代表2020年0810日，活跃用户数为100
当第二天发现数据有需要调整的时候，重新跑一次的时候，这个时候已经是早上十点了，再跑一次，代码没限定时间的，直接把从现在到以前的数据灌进去，咣当，多写了很多行统计数据，看界面数据还是不对，再跑，NIMA，不知道该用哪个了，曾经遇到一个朋友公司每天就在修改这些数据，销售天天吵着
其实，这里唯一索引就派上用场了，,day_time,type字段联合起来建立一个唯一索引，这样随便你数据怎么跑，至少不会多插入数据，永远保证每天每个统计项只有一条数据进去，基本建一个唯一索引，整个系统就可以开始睡大觉了，当然你怕报错，还可以insert ignore into 避免程序执行不完整
其次是用户在一些投票的场景，比如一天一个用户只能对一个投票主题投票一次，这也是同上的，建立一个联合字段的唯一索引，随便你怎么投
有的时候面试我会喜欢问这个问题，因为一般先select出来再判断要不要写入也是可以实现的，但是在高并发条件下这种情况是容易出错的，后面有的同学想到了redis，想到了加锁，没错，都是可以实现的，但是想过效率吗，从本质上看都是一把锁，而问题是这把锁加在了哪里，用MYSQL本身已经实现的唯一索引来实现内部锁的效果还是在外部加一把锁的效果好，没事不加锁是把代码写得溜的另外一种境界
当然在小型统计系统里，你是可以通过一条SQL语句高效的组合成一条结果并且按天按统计项目排序的
简单扯几句，希望有用，大老板们自动略过
