84669 personnes étudient
152542 personnes étudient
20005 personnes étudient
5487 personnes étudient
7821 personnes étudient
359900 personnes étudient
3350 personnes étudient
180660 personnes étudient
48569 personnes étudient
18603 personnes étudient
40936 personnes étudient
1549 personnes étudient
1183 personnes étudient
32909 personnes étudient
最近需要做分表,搜集了一些相关资料,发现分表所带来的一系列问题(如列表显示、数据搜索),代价很高且复杂,且扩展性与后期维护性也很复杂!
搞得不敢用分表了,在想MySQL自带分区功能,为什么都不用呢,偏偏用复杂的分表问题,表示很不解。
如果按取余数来分表,以后再增加表就很麻烦,用一致性哈希算法倒是个好方法,但都面临同一个难题就是查询问题,不知道大家在实际项目中是怎么处理分表问题的?不想用MySQL自带的分表功能,它不是InnoDB的。
业精于勤,荒于嬉;行成于思,毁于随。
菜鸟说下个人的理解哈,个人觉得这个还是要看自己具体业务的需求。比如一些历史数据或者大日志数据,这些数据如果操作性要求不高的话,可以尝试分表。之前处理呼叫中心业务,每天几百万的日志数据,就用的mysql自带的merge引擎分表,业务中主要是单做展示的用途,系统感觉运行的还OK。不过这种用法貌似现在已经不推荐了。现在用的是分区表,数据量也不算大,单表差不多快1000W的数据,性能同样ok。
应该思考一下分表的初心。 分表解决了什么问题,没有解决什么问题。
mysql自带的分表貌似最大只能分1024张表,扩展还是有局限性
菜鸟说下个人的理解哈,个人觉得这个还是要看自己具体业务的需求。比如一些历史数据或者大日志数据,这些数据如果操作性要求不高的话,可以尝试分表。之前处理呼叫中心业务,每天几百万的日志数据,就用的mysql自带的merge引擎分表,业务中主要是单做展示的用途,系统感觉运行的还OK。不过这种用法貌似现在已经不推荐了。现在用的是分区表,数据量也不算大,单表差不多快1000W的数据,性能同样ok。
应该思考一下分表的初心。
分表解决了什么问题,没有解决什么问题。
mysql自带的分表貌似最大只能分1024张表,扩展还是有局限性