初始分库--分表

Auther—Motata

分库/分表

从表由于一直对mysql数据库不是很了解，而这些是必备的基础知识，所以就花了时间从理论上对分库/分表做了些研究希望到使用时不至于太匆忙。可能以下有些地方表述不当，个人理解有些误区或者有错误，请大家指正，大家讨论，共同成长。

大家正常研究问题的路径是，：what（什么）-?why(为什么)-?how(怎么做)，接下来，本文将就这三个问题展开讨论和研究：

• what： 什么是分库分表。英文应该是“shard””Shard” 这个词英文的意思是”碎片”，而作为数据库相关的技术用语，Sharding是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。通过一系列的切分规则将数据水平分布到不同的DB或table中，在通过相应的DB路由 或者 table路由规则找到需要查询的具体的DB或者table，以进行Query操作。这里所说的“sharding”通常是指“水平切分”。

• Why：也就是分库分表意义，一个技术得产生总是因为遇到问题，需要解决，才迫使技术的更新，分库分表也是，假如，如果一个应用至始至终数据量不会超过500w数据，那我想这个应用的owner永远不会去关心它应用的分库分表。例子终究是例子，随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的 互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层 已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台 机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取 （Read）数据的速度和并发量。以上应该就可以很很好的解释分库分表来由。技术的产生总是用来觉得问题的。

• How：如何分库分表，（由于作者对分库分表没有具体实际操作经验，所以文章显示理论较多，等完成一次实际应用中操作补全文章）。数据切分可以是物理 上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。（分库）
  数据切分也可以是数据库内的 ，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表 中，比如将user_id分为auser_id_001, user_id_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的user_id表，这样做的目的其实也是很简单的。比如user_id表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100 个table呢，从user_id _001一直到user_id _100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张 只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好 处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。

分库分表是从数据存储安全，操作可靠性，操作性能等实际业务要求催生出来的技术；分库降低了单点机器的负载；分表提高了数据操作的效率，尤其是Write操作的效率。