基础概念
分表
能够解决单表数据量过大带来的查询效率下降的问题
分库
面对高并发的读写访问，当数据库master服务器无法承载写操作压力时，不管如何扩展slave服务器，此时都没有意义。此时，则需要通过数据分库策略，提高数据库并发访问能力。
优点：
分库、分表技术优化了数据存储方式，有效减小数据库服务器的负担、缩短查询响应时间。
数据分库、分表存储场景条件
-
关系型数据库
-
主从架构(master-slave)
-
单表数据量在百万、千万级别
-
数据库面临极高的并发访问
-
分库、分表实现策略
- 关键字取模，实现对数据访问进行路由。
如何进行数据切分
数据切分（Sharding），简单的来说，就是通过某种特定的条件，将存放在同一个数据库中的数据拆分存放到多个数据库（主机）中，从而达到分散单台机器负载的情况，即分库分表。根据数据切分规则的不同，主要有两种模式，
垂直切分（纵向切分），是对不同的表（或者Schema）进行切分，存储到不同的数据库（主机）之上。
水平切分（横向切分），是对同一个表中的数据进行切分，存储到不同的数据库（主机）之上。规则是根据表中数据的逻辑关系，按照某种条件拆分。
垂直切分
垂直切分，强调的是业务的拆分。一个数据库由多个表构成，每个表对应不同的业务，那么我们可以指按照业务的不同将表进行分类，并将其分布到不同的数据库上，这样就将数据分摊到了不同的库上面，做到专库专用。
举个例子，原数据库中有商品表、交易表、订单表，我们可以按照业务的不同进行垂直切分，把商品表、交易表、订单表分别拆分到商品库、交易库、订单库中去。
垂直拆分的优点：
拆分规则明确，拆分后业务清晰；系统之间进行整合或扩展变的容易；数据维护变的容易；按照成本、应用的等级、应用的类型等将表放到不同的机器上，便于管理。垂直拆分的缺点：
部分业务表无法关联（Join），只能通过接口方式解决，提高了系统的复杂度；受每种业务的不同限制，存在单库性能瓶颈，不易进行数据扩展和提升性能；分布式事务处理复杂。
水平切分（重点）
水平切分，强调的是技术层面的拆分。她是将其按照一定的逻辑规则将一个表中的数据分散到多个库中，在每个表中包含一部分数据，所有表加起来就是全量的数据。简单来说，我们可以将对数据的水平切分理解为按照数据行进行切分，就是将表中的某些行切分到一个数据库表中，而将其他行切分到其他数据库表中。
比如，原数据库有一张交易记录表，数据量非常大，其中表中有个地区字段，经过深入考证符合水平拆分的条件。我们就按照这个字段进行水平拆分，按不同的地区（北京、上海、江苏、浙江、广东等）拆分成10个库。
高峰时段同时有100万次请求，如果是单库，数据库就会承受100万次的请求压力，拆分成100个表分别放入10个库中，每个表进行1万次请求，则每个数据库会承受10万次的请求压力，这样压力就减少了很多，并且是成倍减少的。
水平拆分的优点：
拆分规则抽象好，join 操作基本可以数据库做；不存在单库大数据，高并发的性能瓶颈；应用端改造较少；提高了系统的稳定性跟负载能力。水平拆分的缺点：
拆分规则不好抽象；分片事务一致性难以解决；数据多次扩展难度大；跨库 join 性能较差。
横向/水平分表
作用
解决 表记录太大问题
主要解决问题
单表过大造成的性能问题；
单表过大造成的单服务器空间问题。
按某个字段分
如：将用户资料附件表分成3个附件分表pre_forum_attachment_[0|1|2]，和1个附件索引表（存储tid和附件id关系），根据tid最后一位判断附件保存在哪个分表中。
按日期分表
日志类、统计类数据表按年、月、日、周分表。如：点击量统计statistics_202001、statistics_202002
通过MySQL的merge存储引擎实现
需要创建分表、总表，总表需要merge存储引擎。
示例代码
create table log_merge (
dt datetime not null,
info varchar (100) not null,
index (dt)
) engine = merge
union= (log_2017,log_2018) insert_method = last;
纵向/垂直分表
作用：
解决 列过多问题
常见的方式:
根据活跃度分表、根据重要性分表等。
主要解决问题：
表与表之间资源争用问题；
锁争用机率小；
实现核心与非核心的分级存储，如UDB登陆库拆分成一级二级三级库；
数据库同步压力问题。
具体策略
经常组合查询的列放在一个表，常用字段的表可考虑Memory引擎。
不经常使用的字段单独成表。
把text、blob等大字段拆分放在附表。如：把用户文章表分成主表news和从表news_data，主表存标题、关键字、浏览量等，从表存具体内容、模板等。
分库、分表注意事项
维度问题
针对用户购买记录数据，如果按照用户纬度分表，则每个用户的交易记录都保存在同一表中，所以很快很方便的查找到某用户的购买情况，但是某商品被购买的情况则可能分布在多张表中，查找起来比较麻烦。
若按照商品维度分表，方便查找商品购买情况，但查找个人交易记录比较麻烦。
常见解决方案
通过扫表方式解决，效率太低，不可行。
记录两份数据，一份按照用户纬度分表，一份按照商品维度分表。
通过搜索引擎解决，但如果实时性要求很高，则牵涉到实时搜索问题。
避免分表join操作。关联的表有可能不在同一数据库中。
避免跨库事务
避免在一个事务中修改db0、db1中的表，不仅操作复杂，而且影响效率。
分表宜多不宜少；避免后期可能二次拆分。
尽量同组数据统一DB服务器。例如将卖家a的商品和交易信息都放到db0中，当db1挂了的时候，卖家a相关的东西可以正常使用。即避免多个数据库中的数据产生依赖。
