1. 分区表

主要提供如下的特性，或者适合如此场景：

  • 数据量非常大， 或者只有表中最后的部分有热点数据，其他均为历史数据
  • 分区表数据更容易维护，可以对独立的分区删除等操作
  • 分区表的数据可以分布在不同的物理设备上，从而高效地利用多个硬件设备。
  • 可以避免一些特殊瓶颈，比如InnoDB的单个索引的互斥访问
  • 可以备份和恢复独立的分区

1.1 创建分区表

通常有这么几种分法，因为主键或者是唯一约束键必须有一部分包含在分区键中，所以一般要不无主键，要不就按照自增主键的id进行范围分区，要不就把分区字段和主键一起作为联合主键。
还有一些其他的限制，比如分区键的运算结果必须为整数

Range分区

  1. CREATE TABLE biz_order(
  2. id bigint(20) NOT NULL AUTO_INCREMENT,
  3. created DATETIME NOT NULL COMMENT '创建时间',
  4. PRIMARY KEY (id, created)) ENGINE=InnoDB PARTITION BY RANGE(YEAR(created))(
  5.   PARTITION p_2010 VALUES LESS THAN (2015),
  6.   PARTITION p_latest VALUES LESS THAN MAXVALUE);

这种分区，最新的那个区显然会有最多的热点数据。 可以再使用Hash子分区来减少竞争
- 除了使用YEAR, TO_DAY等日期函数外，还可以使用其数学函数，比如取模，按7取模是周几等

List分区

是用IN来做列值匹配的集合。 比如可以按照地区来分为东西南北几个区：

  1. PARTITION BY LIST(store_id)
  2.     PARTITION pNorth VALUES IN (3,5,6,9,17),
  3.     PARTITION pEast VALUES IN (1,2,10,11,19,20),
  4.     PARTITION pWest VALUES IN (4,12,13,14,18),
  5.     PARTITION pCentral VALUES IN (7,8,15,16)
  6. );

这种如果插入语句不在IN中，则会插入失败

Hash分区

PARTITIONS为分区的数量， 即会根据分区键的值计算出一个hash值，然后以4为模进行存储，好处是，不用再重新建分区了。

  1. PARTITION BY HASH(store_id)
  2. PARTITIONS 4;

还有Key分区，用的太少，不说了

1.2 操作分区表

增加删除分区等语句看这里

分区表由多个底层表构成，底层表跟普通表没什么区别，其索引也是分别在各个表中的索引。 分区表只是会在一个很粗的粒度上决定一下去哪个底层表继续查询。

  • SELECT 锁住底层表，优化器先判断可以过滤部分的分期，然后再调用存储引擎接口访问各个分区
  • INSERT DELETE同行
  • UPDATE 操作会需要设计更新后判断在哪个分区，如果插入到了新分区，那么则删除原分区中的数据。
  • 使用WHERE语句最好能够明确用到分区的关键字，这样可以很好的命中分区
  • 锁住底层表不一定是表锁，会用到存储引擎自己的行级锁

1.3 如何使用

使用分区表肯定是因为数据量非常大，这个时候索引已经不能很好的起作用了。
可以不使用索引，而用粗粒度的命中分区表，然后全表扫描。

或者是针对热点数据，单独使用一个区让这个区都能够放到缓存中，这样就会有一个热点的很小的分区，可以对其使用索引。

另外一些可能的问题：

  • NULL值，因为TO_DAY等方法NULL值为无效入参，会把值放在第一个分区，这个时候SELECT的时候可能会需要查找第一个和命中的分区这样两个分区，这样可能会有很多的性能损耗，解决办法是使第一个分区尽可能的小，第二个办法是直接使用RANGE COLUMNS()而不使用函数
  • 分区列和索引列应该用同一个列，如果不是，会导致无法过滤的问题
  • 寻找分区的成本可能会比较高
  • 维护分区的成本，比如alter等语句改变分区个数，或者其他涉及数据迁移的操作

1.4 分区表的查询

要在WHERE后面带分区列，且不能是表达式
使用EXPLAIN PARTITIONS SELECT来判断是否进行了分区过滤

2. 分表

分区表还是一张表，是一种逻辑上的实现，主要解决的是单表数据过大，索引效率低的问题，很适合大量历史数据，少量活跃数据的场景。把数据保存在不同的区域。

分表是真的有多张表，基于分表还可以做分库，可以提升并发性能，以及磁盘I/O的性能。

二者可以配合使用。

2.1 使用集群的方式

要配合复制使用，仅仅是把查询请求进行了分摊。
但是这样不会影响代码层。

2.2 使用业务逻辑划分

可一个根据用户id来分，每个用户一张表，这样需要每有新的用户都建表了。

还有常用的做法是预先设计好比如100张表，然后对数据的一个字段做hash，然后对100取模。

又或者根据时间来进行分割，这种的好处是，如果根据时间做统计的时候可以不用UNION

上面的分表方式都不能解决根据服务器压力进行选择的问你，并且也不能比较均匀的保存数据。

分表之后要考虑这样几个操作以后可能会带来的问题：

  • 分页， 主要看分页情况下排序的字段是什么，如果是时间，那么按照时间段分表是比较好的， 如果会涉及到多个表的UNION，那么就会比较耗费性能。
  • 插入， 更新。 主要是更新的时候的主键的问题，因为分表之后主键不唯一了，因此需要用分表列和自增列做联合主键。
  • 分组，统计。 这个跟分页考虑的情况差不多，也是主要涉及排序的问题。比如如果每次都是需要按照用户统计信息的话，那么按照用户分表的选择是没错的。
  • 表的分发跟业务很比较大的关系。要尽量考虑比较多的因素和场景。
  • 通用一些的解决办法是，对分页字段使用搜索引擎
  • 或者对分页和排序字段单独列一张表不分，作为查询的索引。

2.3 使用merge存储引擎

  1. 基本表:
  2. CREATE TABLE TEST_MERGE_1(
  3. ID INT(5) NOT NULL,
  4. VALUE VARCHAR(100) NOT NULL,
  5. PRIMARY KEY(ID)
  6. );
  7. CREATE TABLE TEST_MERGE_2(
  8. ID INT(5) NOT NULL,
  9. VALUE VARCHAR(100) NOT NULL,
  10. PRIMARY KEY(ID)
  11. );
  12. MERGE表：
  13. CREATE TABLE TEST_MERGE(
  14. ID INT(5) NOT NULL,
  15. VALUE VARCHAR(100) NOT NULL,
  16. PRIMARY KEY(ID)
  17. ) TYPE=MRG_MyISAM INSERT_METHOD=LAST UNION=(TEST_MERGE_1,TEST_MERGE_2);

基本表必须是MYISAM类型的。
基本表的数据结构必须一致。
order by等语句，我想的是因为Merge表里有基本表共同的索引，所以，排序的时候应该是，都先比较第一个，然后再。。。有点像常用的大文件分成多个小文件，然后分别排序，最后merge的过程。

主要是能够提供比较好的编码界面。