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