随着大数据时代的到来，业务系统的数据量日益增大，数据存储能力逐渐成为影响系统性能的瓶颈。目前主流的关系型数据库单表存储上限为1000万条记录，而这一存储能力显然已经无法满足大数据背景下的业务系统存储要求了。随着微服务架构、分布式存储等概念的出现，数据存储问题也渐渐迎来了转机。而数据分片是目前解决海量数据持久化存储与高效查询的一种重要手段。数据分库分表的过程在系统设计阶段完成，要求系统设计人员根据系统预期的业务量，将未来可能出现瓶颈的数据库、数据表按照一定规则拆分成多个库、多张表。这些数据库和数据表需要部署在不同的服务器上，从而将数据读写压力分摊至集群中的各个节点，提升数据库整体处理能力，避免出现读写瓶颈的现象。
目前数据分片的方式一共有两种：离散分片和连续分片。
离散分片是按照数据的某一字段哈希取模后进行分片存储。只要哈希算法选择得当，数据就会均匀地分布在不同的分片中，从而将读写压力平均分配给所有分片，整体上提升数据的读写能力。然而，离散存储要求数据之间有较强的独立性，但实际业务系统并非如此，不同分片之间的数据往往存在一定的关联性，因此在某些场景下需要跨分片连接查询。由于目前所有的关系型数据库出于安全性考虑，均不支持跨库连接。因此，跨库操作需要由数据分库分表中间件来完成，这极大影响数据的查询效率。此外，当数据存储能力出现瓶颈需要扩容时，离散分片规则需要将所有数据重新进行哈希取模运算，这无疑成为限制系统可扩展性的一个重要因素。虽然，一致性哈希能在一定程度上减少系统扩容时的数据迁移，但数据迁移问题仍然不可避免。对于一个已经上线运行的系统而言，系统停止对外服务进行数据迁移的代价太大。
第二种数据分片的方式即为连续分片，它能解决系统扩容时产生的数据迁移问题。这种方式要求数据按照时间或连续自增主键连续存储。从而一段时间内的数据或相邻主键的数据会被存储在同一个分片中。当需要增加分片时，不会影响现有的分片。因此，连续分片能解决扩容所带来的数据迁移问题。但是，数据的存储时间和读写频率往往呈正比，也就是大量的读写往往都集中在最新存储的那一部分数据，这就会导致热点问题，并不能起到分摊读写压力的初衷。
数据库扩展的几种方式
数据库扩展一共有四种分配方式，分别是：垂直划分，水平划分。每一种策略都有各自的适用场景。
垂直划分
按照功能划分，把数据分别放到不同的数据库和服务器。
当一个网站开始刚刚创建时，可能只是考虑一天只有几十或者几百个人访问，数据库可能就个db，所有表都放一起，一台普通的服务器可能就够了，而且开发人员也非常高兴，而且信心十足，因为所有的表都在一个库中，这样查询语句就可以随便关联了，多美的一件事情。但是随着访问压力的增加，读写操作不断增加，数据库的压力绝对越来越大，可能接近极限，这时可能人们想到增加从服务器，做什么集群之类的，可是问题又来了，数据量也快速增长。
这时可以考虑对读写操作进行分离，按照业务把不同的数据放到不同的库中。其实在一个大型而且臃肿的数据库中表和表之间的数据很多是没有关系的，或者更加不需要（join）操作，理论上就应该把他们分别放到不同的服务器。例如用户的收藏夹的数据和博客的数据库就可以放到两个独立的服务器。这个就叫垂直划分。
垂直分表
垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”。在字段很多的情况下，拆分开确实更便于开发和维护。某种意义上也能避免“跨页”的问题（MySQL、MSSQL底层都是通过“数据页”来存储的，“跨页”问题可能会造成额外的性能开销，这里不展开，感兴趣的朋友可以自行查阅相关资料进行研究）。
拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎。
水平划分
则把一个表的数据划分到不同的数据库，两个数据库的表结构一样。怎么划分，应该根据一定的规则，可以根据数据的产生者来做引导，上面的数据是由人产生的，可以根据人的id来划分数据库。然后再根据一定的规则，先获知数据在哪个数据库。
其实很多大型网站都经历了数据库垂直划分和水平的划分的阶段。其实这个可以根据经验来确定，不一定由某些硬性的规则。
比如说数据可以根据userid的奇偶来确定数据的划分。把id为基数的放到A库，为偶数的放B库。这样每个数据库中的数据量就会相对减少很多，并且可以部署在不同物理服务器上，理论上能够实现数据库的无限横向拓展。所以水平分片是数据库性能问题的最终解决方案。
这样通过userId就可以知道用户数据在哪个数据库。其实可以根据userId%%2==0来处理。还可以根据著名的Hash算法来处理。
当初看手机之家的架构是发现他们是：
水平切分：对数据进行水平分割。
a.最好分到同一个数据库。
b.一种已经证明是切实可行的方案：主表＋辅表。
c.有3种类型：主表不打散、主表打散无辅表、主表打散有辅表。
d.但对程序员来说，TA看到的只是一张表，不妨称之为虚表(逻辑表)? ，这张虚表实际上可能是由N张实表(物理表)组成的。
数据库的基本策略
为了保证数据库的高可用，通常会再加一个数据库与其形成主从关系（Master-Slave），此时所有操作还是由主数据库完成，主数据库再同步到从数据库上，而从数据库只需要在主数据库挂掉之后代替其工作。也就是说此时的从数据库只是为了容灾，对性能没有任何提升。
当遇到第一次数据库性能问题时，最先想到的方案应该是读写分离，将所有写操作都放在主数据库上，所有读操作都放在从数据库上，这样至少可以将主数据库的压力减半，并且由于大部分软件都是读多写少，所以可以配置一主多从进一步减少数据库的读压力。
一般在这时候还会加入缓存（使用 Memcached 或 Redis），与数据库本身没有太大关系就不细说了，一般来说读写分离加上缓存已经可以应付绝大多数情况了，并且几乎不需要对业务层面进行修改。如果再次遇到性能问题，则需要根据业务逻辑进行选择更进一步的方案了，一般有以下几种：
- 对数据库进行垂直分库，将业务彼此无关的表放在单独的数据库中，分库后不同库中的表无法进行联合查询等操作，但是可以平摊压力，并且独立做读写分离。
- 对数据库进行水平分表，建立多个结构相同的表分摊数据，使得每个表的数据量减少从而提升速度。分表和最开始提到的数据库分片看起来很像，实际各有优劣：分表后各个子表还是可以通过 union 等命令联合查询，分库后则不行。但是分库后每个数据库可以独立部署在不同的服务器上，充分利用多台服务器的性能，分表却只能在单台机器的单个数据库上，如果是服务器本身的性能达到瓶颈，则分表不会有明显作用。