MySQL 数据库表分区.

MySQL 数据库在 5.1 版本时添加了对分区（partitioning）的支持。分区的过程是将一个表或索引分解成多个更小、更可管理的部分。就访问数据库的应用而言，从逻辑上来说，只有一个表或一个索引，可是在物理上这个表或索引可能由数十个物理分区组成。

MySQL 分区功能并非在存储引擎层完成的，所以不是只有 InnoDB 存储引擎支持分区，常见的存储引擎 MyISAM、NDB 等都支持。

MySQL 数据库支持的分库类型为水平分区（指将同一表中不一样行的记录分配到不一样的物理文件中），并不支持垂直分区（指将同一表中不一样列的记录分配到不一样的物理文件中）。

MySQL 数据库的分区是局部分区索引，一个分区中既存放了数据又存放了索引。而全局分区是指，数据存放在各个分区中，可是全部数据的索引放在一个对象中。MySQL 数据库目前不支持全局分区。

MySQL 查看数据库分区。

SHOW VARIABLES LIKE '%partitions%';

MySQL 数据库支持如下几种类型的分区。¹ 若是表中存在主键/惟一索引时，分区列必须是主键/惟一索引的一个组成部分。² 对于 RANGE、LIST、HASH 和 KEY 这四种分区中，分区的条件是：数据必须是整型，若是不是整型，那应该须要经过函数将其转化为整型，如 YEAR(),TO_DAYS(),MONTH() 等函数。

• RANGE 分区：行数据基于属于一个给定连续区间的列值被放入分区。
• LIST 分区：和 RANGE 分区相似，只是 LIST 分区面向的是离散的值。
• HASH 分区：根据用户自定义的表达式（能够仅仅是字段列名）的返回值来进行分区，返回值不能为负数。
• LINEAR HASH 分区：线性 HASH 分区，使用的一个线性的2的幂（powers-of-two）算法来肯定新行插入到分区的什么位置。LINEAR HASH 分区的优势在于，增长、删除、合并和拆分分区将变得更加快捷，这有利于处理含有大量数据的表。缺点在于，与 HASH 分区相比，各个分区间数据的分布可能不太均衡。
• KEY 分区：和 HASH 分区相似，不过是根据 MySQL 数据库内部提供的哈希函数来进行分区。
• LINEAR KEY 分区：和 LINEAR HASH 相似，分区的编号是经过2的幂（powers-of-two）算法获得的。
• COLUMNS 分区：¹ 5.5 版本后开始支持，可视为 RANGE 分区和 LIST 分区的一种进化，能够直接使用非整型的数据进行分区，分区根据类型直接比较而得，不须要转化为整型。² 此外，RANGE COLUMNS 分区能够对多个列的值进行分区。³ 对于以前的 RANGE 和 LIST 分区，用户能够用 RANGE COLUMNS 和 LIST COLUMNS 分区进行很好的代替。

子分区（subpartitioning）是在分区的基础上再进行分区，有时也称为这种分区为复合分区（composite partitioning）。MySQL 数据库容许在 RANGE 和 LIST 的分区上再进行 HASH 或 KEY 的子分区。进行子分区后，分区的数量应该为（分区数量 X 子分区数量）个。

MySQL 数据库容许对 NULL 值作分区，视 NULL 值小于任何一个非 NULL 值（和 ORDER BY 处理 NULL 值的规则一致）。

对于 OLAP（在线分析处理） 的应用，分区的确是能够很好地提升查询的性能，由于 OLAP 应用大多数查询须要频繁地扫描一张很大的表。假设有一张 1 亿行的表，其中有一个时间戳属性列。用户的查询依据时间为维度，若是按照时间戳进行分区，则只须要扫描对应的分区便可。

对于 OLTP（在线事务处理）的应用，一般不可能会获取一张大表中 10% 的数据，大部分都是经过索引返回几条记录便可。所以分区应该很是当心，对于一张大表，通常的 B+ 树须要 2~3 次 IO 就能检索到数据。经过根据主键 ID 作 10 个 HASH 的分区后，对于查询就须要扫描全部的 10 个分区，这无疑加剧了 IO 的负担。

咱们经过 Navicat 来操做下数据库分区，表 -> 右键点击'设计表' -> 选项 -> 分割区，能够看到以下内容。

来看看分区后，磁盘中 MySQL 数据库是怎么存储的。

经过 EXPLAIN 分析数据检索的分区。

EXPLAIN PARTITIONS SELECT * FROM t_materiel_config