欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

关于MySQL数据库分表问题

程序员文章站 2022-05-07 18:02:30
...

最近需要做分表,搜集了一些相关资料,发现分表所带来的一系列问题(如列表显示、数据搜索),代价很高且复杂,且扩展性与后期维护性也很复杂!

搞得不敢用分表了,在想MySQL自带分区功能,为什么都不用呢,偏偏用复杂的分表问题,表示很不解。

如果按取余数来分表,以后再增加表就很麻烦,用一致性哈希算法倒是个好方法,但都面临同一个难题就是查询问题,不知道大家在实际项目中是怎么处理分表问题的?不想用MySQL自带的分表功能,它不是InnoDB的。

回复内容:

最近需要做分表,搜集了一些相关资料,发现分表所带来的一系列问题(如列表显示、数据搜索),代价很高且复杂,且扩展性与后期维护性也很复杂!

搞得不敢用分表了,在想MySQL自带分区功能,为什么都不用呢,偏偏用复杂的分表问题,表示很不解。

如果按取余数来分表,以后再增加表就很麻烦,用一致性哈希算法倒是个好方法,但都面临同一个难题就是查询问题,不知道大家在实际项目中是怎么处理分表问题的?不想用MySQL自带的分表功能,它不是InnoDB的。

菜鸟说下个人的理解哈,个人觉得这个还是要看自己具体业务的需求。比如一些历史数据或者大日志数据,这些数据如果操作性要求不高的话,可以尝试分表。之前处理呼叫中心业务,每天几百万的日志数据,就用的mysql自带的merge引擎分表,业务中主要是单做展示的用途,系统感觉运行的还OK。不过这种用法貌似现在已经不推荐了。现在用的是分区表,数据量也不算大,单表差不多快1000W的数据,性能同样ok。

应该思考一下分表的初心。
分表解决了什么问题,没有解决什么问题。

mysql自带的分表貌似最大只能分1024张表,扩展还是有局限性

相关标签: php mysql