首先，公司最近在服务分离、数据分割方面的工作。 因为一张包裹表的数据量太大了，还在增加。 以前知道数据库的分库分表，读过一些博文，但只知道模糊的概念。 而且，现在想起来什么都很模糊。
今天看了下午的数据库分割表，看了很多文章，现在总结一下，“摘录”。 但是，我更期待后期的实际技巧。 从以下几点说。
第一部分：实际网站发展过程中面临的问题。
第二部分：有哪些切法？ 垂直和水平的区别和适用面。
第三部分：目前市场上的开源产品、技术、优缺点是什么？
第四部分：可能是最重要的，为什么不推荐水平分库分表呢！ 这样可以在计划前期慎重对待，避免隔离带来的问题。
名词解释库： database； 表：桌子； 分库分表： sharding
数据库体系结构的演变最初只有独立数据库就足够了。 随后，越来越多的要求，将数据库的写入与读取分离，使用多个从库副本(Slaver Replication )负责读取，使用主库(Master )负责写入模式是数据库主从同步。 更多的读取请求是不成问题的，因为可以从库水平扩展。
但是，用户数量上升后，写入请求越来越多，该怎么办？ 添加母版并不能解决问题。 为了确保数据的一致性，写入操作需要两个主机之间的同步，从而导致重复和更复杂。
在这种情况下，必须使用拆分表(sharding )拆分写入操作。
分库前的问题是每个问题都太大或太小的问题，是这里面临的数据量太大的问题。
用户请求过多是因为单服务器TPS、内存和IO有限。 解决方案：将请求分发到多台服务器； 实际上，用户请求和执行sql查询本质上是相同的，都是请求一个资源。 但是，用户的请求也经由网关、路由、http服务器等。
具有单个库太大、单个数据库处理能力有限的单个库的服务器磁盘空间不足。 在单个库中操作的IO瓶颈的解决方法：切分为更小的库
单表太大，CRUD成为问题的索引膨胀、查询超时的解决方法：分割为多个数据集的更小的表。
分割的方式一般有垂直分割和水平分割。 这是结果集描述的分割方式，是物理空间上的分割。 我们从面临的问题出发，开始解决，首先用户要求量太大，我们会上机解决(这不是本文的重点)
而且单个库太大了。 此时，我们来看看是因为表多而导致数据多，还是单个表中的数据多。 由于表多而数据多的情况下，使用垂直分割，根据业务不同分割为不同的数据库。
使用水平分割，即使一张表的数据量过多，也要按照某种规则将表的数据分割成多个表，甚至是多个数据库上的多个表。分库分表的顺序应该是先垂直分，后水平分。垂直分割更简单，因为它更符合处理现实世界问题的方法。
垂直分割表
也就是说，“用明亮的眼睛摘下小表”是根据列字段进行的。 一般来说，表中字段多、不经常使用的、数据大、长度长的(例如text型字段)会被分割为“扩展表”。 通常，对于数百列明亮的眼睛，也可以避免搜索时数据过多导致的“跨页”问题。
纵向库
垂直分割库以分割一个系统内的不同业务为对象，如用户User个库、商品Producet个库、订单订单个库等。 拆分后，放在多个服务器上，而不是一个服务器上。 为什么？ 想象一下，当购物网站对外提供服务时，会有用户、商品、订单等CRUD。 在被拆分之前，一切都落在单个库中。 这曾使数据库单个库的处理能力成为瓶颈。 如果在垂直拆分库后仍放在一个数据库服务器上，随着用户数量的增加，一个数据库的处理能力将成为瓶颈，一个服务器的磁盘空间、内存、tps等将变得非常紧张。 所以，我们将分割成多台服务器，上面的问题都解决了，今后也不会再面临独立资源的问题。
业务级划分类似于服务的“治理”、“降级”机制，可以对不同业务的数据分别进行管理、维护、监控、扩展等。 虽然数据库容易成为APP应用程序系统的瓶颈，但数据库本身是“有状态的”，很难向Web和APP应用程序服务器“横向扩展”。 的数据库连接资源比较宝贵，单体处理能力也有限。 在高并发情况下，垂直库可以在一定程度上突破IO、连接数和单元硬件资源的瓶颈。
水平分割表
对于数据量大的单张表(例如订单表)，根据某些规则(RANGE，HASH )划分到多个表中。 但是，由于这些表仍然位于同一数据库中，因此库级数据库操作存在IO瓶颈。 不推荐录用。
水平分割表
将一个表中的数据划分为多个服务。 每个服务都有对应的库和表，但表中的数据集合不同。 水平分割表可以有效缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等瓶颈。
水平分割表分割规则
范围
0到10000的表，10001到20000的表；
混型取模
在购物中心系统中，通常将用户、订单作为主表，将它们相关的内容作为附表，避免引起跨库事务等问题。 取用户id，然后hash取模型，分配给不同的东西
的数据库上。地理区域
比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。
时间
按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。
分库分表后面临的问题 事务支持分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
多库结果集合并（group by，order by）TODO
跨库joinTODO 分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。 粗略的解决方法： 全局表：基础数据，所有库都拷贝一份。 字段冗余：这样有些字段就不用join去查询了。 系统层组装：分别查询出所有，然后组装起来，较复杂。
分库分表方案产品目前市面上的分库分表中间件相对较多，TDDL，Cobar，Mycat。
分库分表原则
分表分库虽然能解决光亮的眼睛对数据库系统的压力，但它并不是万能的，也有一些不利之处，因此首要问题是，分不分库，分哪些库，什么规则分，分多少分片。
原则一：能不分就不分，1000 万以内的表，不建议分片，通过合适的索引，读写分离等方式，可以很好的解决性能问题。
原则二：分片数量尽量少，分片尽量均匀分布在多个 DataHost 上，因为一个查询 SQL 跨分片越多，则总体性能越差，虽然要好于所有数据在一个分片的结果，只在必要的时候进行扩容，增加分片数量。
原则三：分片规则需要慎重选择，分片规则的选择，需要考虑数据的增长模式，数据的访问模式，分片关联性问题，以及分片扩容问题，最近的分片策略为范围分片，枚举分片，一致性 Hash 分片，这几种分片都有利于扩容。
原则四：尽量不要在一个事务中的 SQL 跨越多个分片，分布式事务一直是个不好处理的问题。
原则五：查询条件尽量优化，尽量避免 Select * 的方式，大量数据结果集下，会消耗大量带宽和 CPU 资源，查询尽量避免返回大量结果集，并且尽量为频繁使用的查询语句建立索引。