解决亿级数据的mysql分库分表策略

一、背景
在单表数据达到千万，过亿级别时，对数据库操作就非常吃力了，分库分表提上日程，目的很简单，减小数据库的压力，缩短表的操作时间。
二、数据切分策略
数据切分(Sharding)就是通过某种特定的条件，将存放在同一个数据库中的数据拆分存放到多个数据库中，从而达到分散单台机器负载的情况，即分库分表。
根据数据切分规则的不同，主要有两种模式，
垂直切分(纵向切分)，即对不同的表进行切分，存储到不同的数据库上。
水平切分(横向切分)即对同一表的数据进行切分，存储到不同的数据库上。规则是根据表中数据的逻辑关系，按照某种条件拆分。
垂直切分，强调的是业务的拆分。数据库由很多表构成，每个表对应不同的业务，我们可以按照业务的不同将表进行分类，并将其分布到不同的数据库上，这样就将数据分摊到了不同的库上面，做到专库专用。
例如，原数据库中有商品表、交易表、订单表，按照业务的不同进行垂直切分，把商品表、交易表、订单表分别拆分到商品库、交易库、订单库中去。
垂直拆分的优点：
拆分后业务清晰；系统之间进行整合或扩展容易；数据维护容易；便于管理。
垂直拆分的缺点：
部分业务表无法关联(Join)，只能通过接口方式解决，提高了系统的复杂度；受每种业务的不同限制，存在单库性能瓶颈，不易进行数据扩展和提升性能；分布式事务处理复杂。
水平切分，强调的是技术层面的拆分。按照一定的逻辑规则将一个表中的数据分散到多个库中，每个表只含部分数据，所有表加起来就是全量的数据。可理解为按照数据行进行切分，就是将表中的某些行切分到一个数据库表中，而将其他行切分到其他数据库表中。
比如，原数据库有一张交易记录表，数据量非常大，其中表中有个地区字段，经过深入考证符合水平拆分的条件。我们就按照这个字段进行水平拆分，按不同的地区（北京、上海、江苏、浙江、广东等）拆分成10个库。
高峰时段同时有100万次请求，如果是单库，数据库就会承受100万次的请求压力，拆分成100个表分别放入10个库中，每个表进行1万次请求，则每个数据库会承受10万次的请求压力，这样压力就减少了很多，并且是成倍减少的。
水平拆分的优点：拆分规则抽象好，join 操作基本可以数据库做；不存在单库大数据，高并发的性能瓶颈；应用端改造较少；提高了系统的稳定性跟负载能力。水平拆分的缺点：
拆分规则不好抽象；分片事务一致性难以解决；数据多次扩展难度大；跨库 join 性能较差。
三、分库分表存在的问题
共同的缺点，
分布式事务的问题；跨节点 Join 的问题；跨节点合并排序分页的问题；多数据源管理问题。一般来说，业务上存在着复杂 join 的场景是很难切分的，往往业务独立的易于切分。如何切分，我们遵循如下原则，
能不切分尽量不要切分；如果要切分一定要选择合适的切分规则，提前规划好；数据切分尽量通过数据冗余或表分组来降低跨库 Join 的可能；由于数据库中间件对数据 Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表 Join。
四、数据源管理的问题
分库分表之后，数据源的管理是系统实现的关键。
系统应用层面系统应用代码层面，目前主要有两种思路，
客户端模式，每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合。比如可以依赖spring注解实现。中间代理模式，统一管理所有的数据源，后端数据库集群对前端应用程序透明。考虑到系统的复杂性和扩展性，建议第二种中间代理模式。虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来说，是非常实用的。
2. 中间件层面
上面的系统层面，需要的代码实现比较复杂，中间件是在数据集群前面加一层代理，比如Cobar、Mycat等数据库中间件。实用数据库中间件，对代码层面的实现是很大的解放。