前言
关系型数据库比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限，当数据量和并发量起来之后，就必须对数据库进行切分了。
数据切分（sharding）的手段就是分库分表。分库分表有两方面，可能是光分库不分表，也可能是光分表不分库。
数据库分布式的核心内容无非就是数据切分，以及切分后对数据的定位、整合。
为什么要分库分表
分表
单表数据量太大时，会严重影响sql执行的性能。一般单表到达几百万的时候，性能就会相对差一些了，这时就得分表了。
分表就是把一个表的数据放到多个表中，然后查询的时候就查一个表。比如按照项目id来分表：将固定数量的项目数据放在一个表中，这样就可以控制每个表的数据量在可控的范围内。
分库
根据经验来讲，一个库最多支持到并发本文来源gao($daima.com搞@代@#码(网52000时就需要扩容了，而且一个健康的单库并发值最好保持在1000左右。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。
这就是所谓的分库分表，为啥要分库分表？
- 提高并发支撑能力
- 降低磁盘使用率
- 提高SQL执行性能
如何分库分表
直接看图：
对于垂直拆分，建议最好在系统设计之初做好表设计，避免垂直分表。
水平拆分可以按照range来分，或是按照某个字段hash。按照range来分，好处在于扩容简单，准备好新的表或库就可以了。但是容易产生热点问题，实际使用时要结合业务场景来看。按照hash来分，好处在于可以平均分配每个库或表的请求压力，缺点是扩容麻烦，之前的数据要rehash，存在一个数据迁移的过程。
分库分表带来的问题
分库分表能有效地缓解单机和单库带来的网络IO、硬件资源、连接数的压力。但也带来了一些问题。
- 事务一致性问题
通过分布式事务或者保证最终一致性来解决。 - 跨节点关联查询join问题
全局表、字段冗余、数据组装、ER分片 - 跨节点分页、排序、聚集函数问题
首先在不同分片节点进行查询，最后要对结果进行汇总或归并 - 全局主键避重问题
各种分布式ID生成算法 - 数据迁移、扩容问题
如果是range分片，只需要添加节点就可以进行扩容了。
如果是hash，一般做法是先读出历史数据，然后按指定的分片规则再将数据写入到各个分片节点中。
数据迁移
数据迁移介绍两种方案。
一个最low的方案，就是系统停机一段时间，用实现写好的导数据的工具跑一遍把单独单表的数据独出来，写到分库分表里面去。
第二个方案听起来就比较靠谱了，双写迁移方案。在线上系统里，之前所有写数据的地方，增删改操作，除了对旧库增删改，再加上对新库的增删改，这就是所谓的双写。然后系统部署之后，把方案一里的导数据工具跑起来，读老库写新库。写的时候要根据gmt_modified这类字段判断这条数据最后修改的时间，除非是读出来新库没有，或是比新库数据新才会写。简单来说就是不允许用老数据覆盖新数据。
写完一轮之后，有可能还是存在不一致，那么就程序自动新一轮校验，对比新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环直到数据完全一致。
中间件
转载请注明原文链接：MySQL分库分表与分区的入门指南
