[高并发问题] MySQL 分区的情况下不能使用自增 ID,若使用 UUID 与时间做联合主键,数据量特大时,查询库效率如何?
业务背景:
每天会有1000~3000万条数据入库
每条数据入库后会有多次查询
每条数据入库时需要检查用户余额,并扣除余额
热数据只有10分钟,也就是这些数据入库后10分钟内会重复多次使用,然后每天凌晨会对前一天的数据作一次数据统计
我现在的准备使用的方式是:
使用时间字段入库表进行分区,每天建一个新的分区,旧分区保存7天(使用MYSQL 事件操作)
因为MYSQL分区之后,没有自增ID,于是我使用UUID的方式做ID,又因为需要使用时间来分区的关系,所以我的联合主键是 (时间,UUID)。
用户信息保存到redis,验证用户余额时直接判断缓存余额够不够。若缓存够,直接update money = money - cost 。会有一个余额扣负仍然可用的问题。缓存1分钟更新。
查询结果也保存到了缓存,先查缓存
存数据的时只有2条写库SQL语句 1条插入数据、1条改用户余额
查询的时候,也加了缓存
现在的问题是:
1.当这个表超大时,或达到7天时间,极限可能会有2亿多数据,此时根据UUID去查一条记录的时候会不会非常慢?有什么优化方法?
2.因为UUID是字符串,前后可能不连续,所以它没办法使用2分查找,索引可能效果也不是特别好?在数据量特别大的情况下UUID是否不适合做主键?
自己思考:如果我再额外建立int类型的索引字段,在高并发的情况下,我没法保证效率和唯一性,若每次都去查一下数据库找到最大值(可以放到缓存),再入库?感觉这个方法也可能会有风险。
3.update money = money - cost 这种方式扣用户余额,在高并发情况下有问题吗?
4.MYSQL事件删除旧分区时,因为数量很大,会不会导致数据库很慢?
5.最后一个问题,这样的业务环境,使用MYSQL分区好,还是用程序每天建一个新表?(建新表方式开发成本较高,但可以使用自增ID,不用UUID)
大神们若有合适的方案还请不吝赐教
推荐文章: