在介绍分库分表中数据同步的问题与解决方案之前，首先介绍下分库分表的相关内容。
分库分表的原因（以MySQL为例）
1、随着数据量增大，数据查询速度会逐渐下降，分库分表（当然不是唯一方案）就可以减小数据库的负担，缩短查询时间。
2、MySQL具有行锁和表锁的机制，目的是为了保证数据的一致性，以表锁举例，若要对其进行操作需要等到表锁释放后才可以。
分库分表的方案
1、MySQL的主从复制，实现了数据库的读写分离，很好的提高了读的性能。
2、垂直分片，如果业务切割的足够独立，可以考虑将不同的业务数据放到不同的数据库服务器，可以实现解耦、负载分流的能力，大大提升数据库的吞吐能力。
3、水平分片，以用户表举例，将用户按照一定的规则进行分组，将不同的组存储到不同的数据库分片。（至于如何识别用户在那个数据库的哪个分片中，有很多方式，如添加中间记录表，或者从规则入手）
上述的三种方案是可以相互结合的，在进行分库分表的设计是要考虑到分库分表的规则，如新增用户时，应将此数据添加到具体哪个表中，查询用户时，怎样确定该记录具体在个表中。
如 计划将user表拆分为三张user表 user_01,user_02,user_03,分表规则为（user_id%3） +1
因此若插入user_id 为200，则插入的表应为user_003,查询同理。
分库分表维度问题
用于购买一件商品，产生交易记录将其保存。
若按照用户维度将数据分表，则交易记录表可根据用户实现快速查询，但是根据商品查询则相对复杂。反之，按照商品维度分表，可以根据商品实现快速查询，但要查找用户的交易记录比较麻烦。
解决方式：空间换时间，将两个维度的数据分别进行存储，一份按照用户维度，一份按照商品维度。
以及其他问题：如联合查询、跨库事务等。
分库分表的时机
MySQL提供读写分离机制，写操作对应Master，读操作对应Slave，Mater同步Slave有一定的延迟，因此随着Master繁忙时延迟问题会更加严重，Slave机器数量的增加也会使这个问题严重，当写操作过多时，严重影响Master稳定性，如果Master挂掉，整个集群无法工作。
因此：当读压力过大时可以考虑增加Slave，当Slave数量过多时可以考虑分库了。但是当写压力过大时，就必须进行分库操作了。
参考：https://www.toutiao.com/a6603492496779510276/?tt_from=mobile_qq&utm_campaign=client_share×tamp=1549497188&app=news_article&utm_source=mobile_qq&iid=59568063679&utm_medium=toutiao_android&group_id=6603492496779510276
