单库单表是最常见的数据库设计，例如，有一张用户(user)表放在数据库db中，所有的用户都可以在db库中的user表中查到。
当一张表的数据达到几千万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。
把存于一个库的数据分散到多个库中，把存于一个表的数据分散到多个表中。如果说读写分离是为了分散数据库读写操作压力，分库分表就是为了分散存储压力
视频地址: https://www.bilibili.com/video/BV1zy4y1m7ZS/
在互联网时代，随着业务数量的暴增和应用规模的不断扩大，无论是oracle还是mysql这样子的关系型数据库，都会面临服务器CPU、磁盘IO和内存的各种瓶颈问题。基于此情况，各个业务团队迫切需要一种数据分片的方案将业务数据量存储成本分摊到成本可控的各个普通数据库服务器上，数据库切分的方案便应运而生。
：http://blog.csdn.net/xlgen157387/article/details/51331244
在传统的中小公司里面，尤其是以企业内部的办公系统、REP系统，或者体量不是很大的互联网公司里面，搭建一套单库和单表足以应对生产的业务数据量了。而在一些互联网大公司里面，单表每天有上100w的数据业务增量时，就要考虑分库分表的策略了。否则，无论是数据的存储、访问、更新等操作，单库和单表都会影响系统和数据库的性能。
为什么要分表和分区？ 日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。
在 MySQL 集群架构中有两种主流的集群实现，一种是读写分离，而另外一种则是数据分片。所谓的数据分片其实就是今天要聊的分库分表技术。
文章集中整理总结mysql分库分表开源产品，分布式数据库的设计，以及实际应用案例等相关内容，部分附上本文作者实际应用过程中的理解。
缘起：有个朋友问我分区表在58的应用，我回答不出来，在我印象中，百度、58都没有听说有分区表相关的应用，业内进行一些技术交流的时候也更多的是自己分库分表，而不是使用分区表。于是去网上查了一下，并询问了58到家的DBA专家，将自己收到的信息沉淀下来，share给大伙。
1 分库分表，我们使用业务逻辑 + 业务程序的方式来进行，并期根据实际的环境将系统中的一些表分割到不同的MYSQL 服务器上存储，达到以下两个关键问题的解决。
分片策略（如果要看各个策略的实际操作，看ShardingSphere专题视频即可）
缘起：有个朋友问我分区表在58的应用，我回答不出来，在我印象中，百度、58都没有听说有分区表相关的应用，业内进行一些技术交流的时候也更多的是自己分库分表，而不是使用分区表。于是去网上查了一下，并询问了58到家的DBA专家，将自己收到的信息沉淀下来，share给大伙。 解决什么问题？ 回答：当mysql单表的数据库过大时，数据库的访问速度会下降，“数据量大”问题的常见解决方案是“水平切分”。 mysql常见的水平切分方式有哪些？ 回答：分库分表，分区表 什么是mysql的分库分表？ 回答：把一个很大的库（表）
前两篇文章重点讲到了Mysql数据库的主从同步和读写分离，使用主从同步实现从数据库从主数据同步数据保持主从数据一致性，读写分离使用主数据库负责写操作，多个从数据库负责读操作，由于从库可以进行拓展，所以处理更多的读请求也没问题。但是如果业务比较多，写请求越来越多要如何处理呢？可能有人说我可以再加一个master分担写操作，但是两个master数据肯定是需要同步的，主主同步 + 主从同步很显然会让我们的系统架构变得更为的复杂。所以本篇文章主要讨论一个对写操作进行切分的技术：分库分表。
在系统初期，整体的并发了相对较小，因此一般都是将所有的数据信息存储在单库中进行读/写操作。但是随着用户规模不断提升，单库逐渐力不从心，TPS/QPS越来越低。因此到了这个时候，dba会将数据库设置为读写分离状态（生产环境一般会采用一主一从或者一主多从），Master负责写操作，Slave作为备库，不开放写操作，但是允许读操作，主从之间保持数据同步即可。 读写分离之后，可以大大提升单库无法支撑的负载压力 需要注意的是：如果Master存在TPS存在较高的情况，Master之前最好将同一份数据落到缓存中，以避免高并发情况下，从Slave中获取不到指定数据的情况发生 [MySQL 主从同步延迟的原因及解决办法(https://blog.csdn.net/soar_away/article/details/72615012)
主从模式对于写少读多的场景确实非常大的优势，但是总会写操作达到瓶颈的时候，导致性能提不上去。
我们平时做项目开发。一开始，通常都先用一张数据表，而一般来说数据表写到2kw条数据之后，底层B+树的层级结构就可能会变高，不同层级的数据页一般都放在磁盘里不同的地方，换言之，磁盘IO就会增多，带来的便是查询性能变差。如果对上面这句话有疑惑的话，可以去看下我之前写的文章。
文章摘要：当单表数据达到千万以上时，通过加索引或者表分区优化提升的效果就比较有限了，应该如何应对呢？？？
今天是《分库分表 ShardingSphere 原理与实战》系列的开篇文章，之前写过几篇关于分库分表的文章反响都还不错，到现在公众号:程序员小富后台不断的有人留言、咨询分库分表的问题，我也没想到大家对于分库分表的话题会这么感兴趣，可能很多人的工作内容业务量较小很难接触到这方面的技能。这个系列在我脑子里筹划了挺久的，奈何手说啥也不干活，就一直拖到了现在。
当MySQL单表的数据量过大时，数据库的访问速度会下降，“数据量大”问题的常见解决方案是“水平切分”。
传统的将数据集中存储至单一数据节点的解决方案，在容量、性能、可用性和运维成本这三方面难于满足海量数据场景。在单库单表数据量超过一定容量水位的情况下，索引树层级增加，磁盘 IO 也很可能出现压力，会导致很多问题。
数据库在业务体系不大的情况，一般都是单库出现，通过增加主从复制提高SLA。但当业务体量不断扩大，就需要考虑进行数据拆分来解决性能瓶颈问题。
这个你必须面对的事，就是当你已经弄好分库分表方案，测试也通过了，数据能均匀分布到各个库和表里去，而且接着你还通过双写方案上了系统，已经直接基于分库分表方案在搞了。
为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们具体是如何对数据库如何进行垂直拆分或水平拆分的？
项目前期基本都是单库单表，单库单表也是最常见的数据库设计，比如说：有一张用户表User，被放到数据库中，所有的用户的信息都被存储在该数据库的这张User表里。
突然! 扩容了，扩容成6个库，每个库需要12个表，你怎么来增加更多库和表？ 当你已经弄好分库分表方案，测试也通过了，数据能均匀分布到各个库和表里去，而且接着你还通过双写方案上了系统，已经直接基于分库分表方案在搞了。 需求来了~现在这些库和表又支撑不住了，要继续扩容，咋办？
当我们业务数据库表中的数据越来越多，如果你也和我遇到了以下类似场景，那让我们一起来解决这个问题
传统的将数据集中存储至单一数据节点的解决方案，在容量、性能、可用性和运维成本这三方面难满足海量数据场景。在单库单表数据量超过一定容量水位的情况下，索引树层级增加，磁盘I/O也很可能出现压力，会导致很多问题。
数据库很容易成为系统性能的一个瓶颈，单机存储容量、IO、CPU处理能力都有限，当单表的数据量达到1000W或100G以后，库表的增删改查操作面临着性能大幅下降的问题。存储容量现在一般容易解决，主要是IO瓶颈和CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。从业务方来看，就是数据库可用连接少，甚至无连接可用。
参数优化 ===> 缓存、索引 ====> 读写分离====> 分库分表 （最终方案）
最近遇到一个慢sql，在排查过程中发现和分库分表后的索引设置有关系，总结了下问题。
对于分库分表来说，具体有两种方式：垂直拆分和水平拆分。 垂直拆分主要是业务的细化和独立，和业务联系比较密切。所以本文只讨论更通用的水平拆分。
上文讲到，查询分离的方案存在三大不足，其中一个就是：当主数据量越来越大时，写操作会越来越缓慢。这个问题该如何解决呢？可以考虑分表分库。
众所周知，数据库很容易成为应用系统的瓶颈。单机数据库的资源和处理能力有限，在高并发的分布式系统中，可采用分库分表突破单机局限。本文总结了分库分表的相关概念、全局ID的生成策略、分片策略、平滑扩容方案、以及流行的方案。
首先我们要知道分库、分表都是干啥的，本文主角还是我们的MySQL为第一视角。首先从字面意思来看：
今天，探讨一个有趣的话题：MySQL 单表数据达到多少时才需要考虑分库分表？有人说 2000 万行，也有人说 500 万行。那么，你觉得这个数值多少才合适呢？
一般情况下我们创建的表对应一组存储文件，使用MyISAM存储引擎时是一个.MYI和.MYD文件，使用Innodb存储引擎时是一个.ibd和.frm（表结构）文件。
举例：一个用户表有很多的属性,关联了很多数据,如果放到同一个表里面的话查询是方便了,但是效率不行。
刚开始多数项目用单机数据库就够了，随着服务器流量越来越大，面对的请求也越来越多，我们做了数据库读写分离， 使用多个从库副本（Slave）负责读，使用主库（Master）负责写，master和slave通过主从复制实现数据同步更新，保持数据一致。slave 从库可以水平扩展，所以更多的读请求不成问题
分表和分区看起来十分类似，确实，分区已经能够在磁盘层面将一张表拆分成多个文件了，理论上前面提到的大表的问题都能得到有效解决。因为分区就是分表的数据库实现版本。
不管是为了满足业务发展的需要，还是为了提升自己的竞争力，关系数据库厂商（Oracle、DB2、MySQL 等）在优化和提升单个数据库服务器的性能方面也做了非常多的技术优化和改进。但业务发展速度和数据增长速度，远远超出数据库厂商的优化速度，尤其是互联网业务兴起之后，海量用户加上海量数据的特点，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群的方式来提升性能。
对分表键(shardkey)做murmurHashCodeAndMod运算, 数据均匀分布在每个set上(这个说法其实不严谨)
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
