共计 1493 个字符，预计需要花费 4 分钟才能阅读完成。
本篇文章为大家展示了 MySQL 中如何实现分库分表，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
一、 背景介绍
1．大数据量的存储需要大量的资源；
2．数据量的不断增长要求数据库存储具有可扩展性；
3．在保证大数据量的情况下，要保证性能、高可用性等质量要求；
4．现有框架中没有彻底解决大数据量的存储问题；
5．等海量存储方案价格不菲，采用 MySQL 进行分库分表节约 IT 成本。
二、 可行性分析
1. 风险评估
1) DBA 数据库管理的资源和规范要求；
2. 业务数据量规模和变化的影响
1) 对于事先可规划的中等以上数据规模，采用单库分表（一个数据库实例，分多张表）、读写分离、或者多库多表（多个数据库实例，多张表）可以满足业务需求，且相应设计和实现相对简单，不易出错。
2) 对于初期数据规模不可准确预知，但随着业务发展数据规模不断增长的系统，要求数据存储具有可扩展性。这种可扩展性通过分库分表解决，要求分库分表在路由上具有极强的伸缩性，这也是分库分表的难点，本方案提出一个循序渐进的实现路线逐步解决这个问题。
3. 技术积累
1) 公司已有简单的分库分表方案
2) 这个方案缺乏扩展性
3) 本方案将提出短期实现一定扩展性、中长期高可扩展性的方案
4. 开源或产品
1) 商业版数据库 Sharding：MySQL Proxy，提供 MySQL 协议接口（非 JDBC），主从结构，可以负载平衡，读写分离，failover 等，lua 语法复杂，不支持大数据量的分库分表；
2) Amoeba，支持分数据库实例，每个数据相同的表，不支持事务；类似 MySQL Proxy，设计上抛弃 lua，更简单；
3) 阿里集团研究院开源的 CobarClient，主要面向小规模的数据库 sharding 集群访问，基于 ibatis，需要规划数据规模，缺乏扩展性；另外有 Cobar，阿里集团内部的一个完整 DAL 层，实现完整 JDBC 代理；
4) HibernateShards，Hibernate 提供的 sharding，支持分数据库实例，比较复杂，事先规划数据规模，和框架不符；
5) guzz，多库（虚拟的数据库，实际数据库的路由规则仍然自定义）、表分切、读写分离，以及多台数据库之间透明的分布式事务支持，设计目标是支持大型在线生产应用；需完全替换 ibatis；完全和框架不符。
6) TDDL，淘宝的 DAL，很强的分库分表能力，仍然需要数据量实现规划，动态扩展有限。
7) 以上某些产品在一定程度上可以满足我们的需求，但不能彻底解决我们大数据量可扩展的问题。
三、 性能指标
1. 和没有引入分库分表时相比，每次操作最大延迟 1ms；
四、 特性列表和 RoadMap
1. 垂直分库，不同业务数据使用不同数据库实例存储
2. 数据切分：
a) 根据切分字段 Hash 取模；
b) 确定需要切分的数据，尽量将可能进行关联的分片数据放在一个数据库实例中，例如同一用户的基本信息、好友信息或者文件信息等；
3. 短期：分库分表
a) 数据库实例编号递增
b) 每个数据库内分表序号从 1 递增，不全局编号
c) 基于数据源（ibatis 基础上）拦截建立访问层，应用感知
d) 应用需在底层进行数据源、分布式事务考虑和管理等
e) 可扩展性：只支持向上扩展，不支持收缩
4. 长期：数据库访问层
a) 建立灵活的数据切分和路由规则
b) 支持 MySQL 集群
c) 读写分离和负载均衡
d) 可用性探测
e) 分布式事务
f) 对应用透明
上述内容就是 MySQL 中如何实现分库分表，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注丸趣 TV 行业资讯频道。
