有一定数据规模的公司一般都有分库分表的策略，本文记录本人在工作遇过的分库分表策略，分库和分表的逻辑差不多，所以在本文我们认为分库和分表是一个概念。
按照业务垂直划分
比如我是一家酒店OTA，对外提供酒店预定服务。显而易见，在数据库中存着房间的状态信息。我们可以想象得到一线城市查看率、预订率和交易额占比是非常大的。在这种情况下，我们就可以根据业务把热门的城市数据放在不同的分片里。热门城市各自单独分片，冷门城市放在一个分片里。数据库看起来像这样，hotel_shenzhen,hotel_beijing
好处： 在项目启动的时候一般都会做一些预热处理，以达到快速响应的目的。这样做的好处，根据地区进行分库，省去了其他地区的查询条件，在做索引重建，数据录入等操作的时候逻辑简单，效率高。
适合场景： 这种方法适合业务可以垂直拆分的场景，耦合度低。
水平拆分
酒店的订单中心拥有庞大的数据量，但是订单无法进行业务垂直拆分。这种情况可以进行水平拆分，拆分可以以订单的流水号为依据，比如根据ID范围划分，根据ID哈希划分。最终数据库看起来像这样：db1.tb1，db1.tb2,db2.tb1，db2.tb2......
关于事务
分库分表对事务的支持会变得很难，XA事务实现起来也是有一定性能代价的。所以为了保证数据一致性，要根据具体情况具体分析了。有零事务的、有二段式提交的。
关于跨库跨表查询
首先说明一点，博主是在互联网行业工作，所以平时几乎不写联合查询SQL，所以本节的前提是假定为单表查询。
跨库跨表查询都要根据shard_id进行数据定位。所以有点规模的公司都会有自己的中间件，做数据的组装。
总结
数据库拆分分为垂直拆分和水平拆分。垂直拆分大多是业务层次的拆分，而水平拆分则为同一业务的水平扩展。在大多数的情况下应该是这样：先垂直拆分业务，然后再对业务进行水平拆分。