共计 3047 个字符，预计需要花费 8 分钟才能阅读完成。
MySQL 中怎么实现数据切分，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
什么是 MySQL 数据切分
Shard 这个词英文的意思是 碎片，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏中。Sharding 姑且称之为 分片。Sharding 不是一门新技术，而是一个相对简朴的软件理念。众所周知，MySQL5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。
数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢答案是：Sharding。Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展 (ScaleOut，亦或横向扩展、向外扩展) 的解决方案，其主要目的是为突破单节点数据库服务器的 I / O 能力限制，解决数据库扩展性问题。
通过一系列的切分规则将数据水平分布到不同的 DB 或 table 中，在通过相应的 DB 路由或者 table 路由规则找到需要查询的具体的 DB 或者 table，以进行 Query 操作。这里所说的“sharding”通常是指“水平切分”，这也是该篇文章讨论的重点。具体将有什么样的切分方式呢和路由方式呢? 行文至此，读者难免有所疑问，接下来举个简单的例子：我们针对一个 Blog 应用中的日志来说明，比如日志文章 (article) 表有如下字段：article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int).
面对这样的一个表，我们怎样切分呢? 怎样将这样的数据分布到不同的数据库中的表中去呢? 其实分析 blog 的应用，我们不难得出这样的结论：blog 的应用中，用户分为两种：浏览者和 blog 的主人。浏览者浏览某个 blog，实际上是在一个特定的用户的 blog 下进行浏览的，而 blog 的主人管理自己的 blog，也同样是在特定的用户 blog 下进行操作的(在自己的空间下)。所谓的特定的用户，用数据库的字段表示就是“user_id”。就是这个“user_id”，它就是我们需要的分库的依据和规则的基础。我们可以这样做，将 user_id 为 1～10000 的所有的文章信息放入 DB1 中的 article 表中，将 user_id 为 10001～20000 的所有文章信息放入 DB2 中的 article 表中，以此类推，一直到 DBn。
这样一来，文章数据就很自然的被分到了各个数据库中，达到了数据切分的目的。接下来要解决的问题就是怎样找到具体的数据库呢? 其实问题也是简单明显的，既然分库的时候我们用到了区分字段 user_id，那么很自然，数据库路由的过程当然还是少不了 user_id 的。考虑一下我们刚才呈现的 blog 应用，不管是访问别人的 blog 还是管理自己的 blog，总之我都要知道这个 blog 的用户是谁吧，也就是大家都明白了这个 blog 的 user_id，就利用这个 user_id，利用分库时候的规则，反过来定位具体的数据库，比如 user_id 是 234，利用该才的规则，就应该定位到 DB1，如果 user_id 是 12343，利用该才的规则，就应该定位到 DB2。以此类推，利用分库的规则，反向的路由到具体的 DB，这个过程我们称之为“DB 路由”。
当然考虑到数据切分的 DB 设计必然是非常规，不正统的 DB 设计。那么什么样的 DB 设计是正统的 DB 设计呢?
我们平常规规矩矩用的基本都是。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的 Replication 机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的(下文会提及)。上面提到的“自觉的按照范式设计”。考虑到数据切分的 DB 设计，将违背这个通常的规矩和约束，为了切分，我们不得不在数据库的表中出现冗余字段，用作区分字段或者叫做分库的标记字段，比如上面的 article 的例子中的 user_id 这样的字段(当然，刚才的例子并没有很好的体现出 user_id 的冗余性，因为 user_id 这个字段即使就是不分库，也是要出现的，算是我们捡了便宜吧)。当然冗余字段的出现并不只是在分库的场景下才出现的，在很多大型应用中，冗余也是必须的，这个涉及到高效 DB 的设计，该篇文章不再赘述。
为什么要 MySQL 数据切分
上面对什么是数据切分做了个概要的描述和解释，读者可能会疑问，为什么需要数据切分呢? 像 Oracle 这样成熟稳定的数据库，足以支撑海量数据的存储与查询了? 为什么还需要数据切片呢? 的确，Oracle 的 DB 确实很成熟很稳定，但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的。试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑，这是一般公司能支付的起的吗? 即使就是能支付的起，如果有更好的方案，有更廉价且水平扩展性能更好的方案，我们为什么不选择呢?
但是，事情总是不尽人意。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的 Replication 机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的。首先它的有效很依赖于读操作的比例，Master 往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话 Master 首先扛不住，Slaves 的数据同步的延迟也可能比较大，而且会大大耗费 CPU 的计算能力，因为 write 操作在 Master 上执行以后还是需要在每台 slave 机器上都跑一次。这时候 Sharding 可能会成为鸡肋了。
Replication 搞不定，那么为什么 Sharding 可以工作呢? 道理很简单，因为它可以很好的扩展。大家都明白每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是横向扩展, 通过添加更多的机器来共同承担压力。我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通过线性增长就能满足需求?Sharding 可以轻松的将计算，存储，I/ O 并行分发到多台机器上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。
综合以上因素，数据切分是很有必要的，且我们在此讨论的数据切分也是将 MySql 作为背景的。基于成本的考虑，很多公司也选择了 Free 且 Open 的 MySql。对 MySql 有所了解的开发人员可能会知道，MySQL5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢答案也是 Sharding，也就是我们所说的数据切分方案。
关于 MySQL 中怎么实现数据切分问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
