一、优缺点： http://www.Sina.com/http://www.Sina.com/http://www.Sina.com/3358 www.Sina.com so，一般进行表的水平分割，另一个主多从，读写分离。优点：(可扩展性问题：为什么会牺牲性能)传统解决方案：如果一个事务同时包含读请求(如select )和写请求(如insert ) 在跨多个库的情况下，本地事务变得无法控制，属于分布式事务的范畴。分布式事务非常复杂，效率低下。 因此，对于读写分离，本地事务就足够了，因为事务中的所有sql都是统一去主库的，而且只涉及一个库。 水平扩展能力低，根据选择的分片规则为架构相对简单
1 .表格结构变更(DDL )操作困难，容易出错
2 .分片维护(备份、恢复操作)单机事务延迟低，应用充分适配后（全单机事务）可以在位置原有延迟低基础上获得TPS的线性提升数据从主节点通过网络同步到多个slave节点，因此必然存在延迟。 因此，可能会出现将数据插入master节点但无法从slave节点读取的问题。 在一致的业务场景中，插入后必须是可读的，因此在这种情况下，需要提供一种方法，使读请求也可以移动到主库中。 主库中的数据一定是最新的。 2 .水平和垂直分割对底层的关系型数据库改动不大，运维经验可以复用sql解析：首先解析sql，得到要插入的四个记录的id字段的值分别为1、2、3、4sql根。 SQL路由包括库路由和表路由。 库路由确定要插入此记录的库，而表路由确定要插入此记录的表。 sql重写：由于一个记录只能插入到一个库中，因此上述批量插入语法在每个库中插入四个记录，显然不合适，因此必须重写sql。 每个库只能插入一条记录。 执行sql :一个sql已重写为多个sql。 为了提高效率，必须同时在不同的库中运行结果集，而不是按顺序运行一个结果集。 每个sql运行后都有运行结果。 必须合并按库列出的表的结果集以获得完整的结果。缺点：需要全球身份生成器。 目前分布式id有很多中方案，其中一个比较轻量级的方案是twitter的snowflake算法。只适用于简单业务，同时对业务有侵入性，需要改造mysql支持XA事务，但效率低下。 柔性事务是当前主流的方案，柔性事务包括最大努力通知型、可信消息最终完整性方案和TCC两级提交。 但是，无论是XA事务还是柔性事务，实现都非常复杂。 总结方案如下。 1.XA方案2.TCC方案3 .本地消息表4 .可信消息最终匹配方案5 .最大努力通知方案很难支持跨分片的高性能复杂查询动态扩展是指增加分库分表的数量。