压倒90%程序员的面试题：分库分表有哪些弊端？
表的数据太大的时候都会习惯性的去分库分表，分库分表会带来哪些弊端你了解过吗？
18年程序员面试。表的数据太大的时候都会习惯性的去分库分表，丰富分表会带来哪些弊端你了解过吗？
如果数据在不同的库或者表里面可能会导致查询的时候要跨库或者跨表查询，从而会可能降低查询的性能。你刚刚说你精通卖搜口，看来不是吹牛的，回答的还是挺在点的。
好的面试官。
·首先分库分表分为纵向分表与横向的分表。所谓纵向的分库分表其实就是对于业务进行微服务拆分以后，每个业务的数据都可以进行拆分，包括拆分成不同的实例库来降低不同业务的数据的耦合度。微服务拆分以后服务本来就是分开的。
另外我准备了一份Java程序员任务模块手册，里面包含了简洁模板热门面试题以及弹性技巧，如果有需要可以在评论区留言领取。所以纵向的分库分表是没有什么问题的。
主要的问题在于横向的分库分表。所谓横向的分库分表是某个业务表的数据过大的时候，为了提升性能拆分到不同的表跟库，这个时候可能会有以下几个问题。
·第一点、事物不能再用本地事物了，需要引入seata等分布式的事物。
·第二点、因为是统一业务，可能避免不了需要进行跨表分页或者说歪念查询，这样反而需要跨更多的表来进行查询聚合。这个可以通过采用shardingsphere插件来提升快表的性能或者直接引入ES分布式搜索组件，当然也会带来一些数据同步的问题。
·第三点、分库分表是将数据放到不同的库跟表，会有一定的算法，比如取模分档。当扩容的时候数据迁移会比较麻烦。
·第四点、也就是比较多的 id 问题。当数据在不同的表的时候，如果用数据的自增来做数据的主键，那么不同的表可能ID重复，所以需要引入一些分布式的ID解决方案，比如雪花算法、readys的increase命令等等来做分布式ID。
这是我对这个问题的理解。好的，谢谢你来参加今天的面试，等一下，我还有个会议就不送你出去了。
