MySQL 5.1 分区支持 _MySQL 数据库表分区

MySQL数据库在5.1版本中引入了对分区的功能。这一过程涉及将单一表或索引拆分为若干更小、更易于管理的部分。对于访问数据库的应用来说，从逻辑层面看，似乎仅涉及一个表或一个索引，然而在物理层面，该表或索引可能由多达数十个物理分区构成。

MySQL的分区操作并非在存储引擎这一层面实现，所以并非仅有特定的存储引擎能够实现分区功能，诸如、以及NDB等众多常见的存储引擎均具备这一支持能力。

MySQL数据库所采纳的分库方式主要是水平分区，即同一表中的不同行记录会被分散存储到不同的物理文件中；然而，它并不支持垂直分区，后者是指将同一表中的不同列记录分别存储在不同的物理文件里。

MySQL数据库的分区方式涉及局部分区索引，即每个分区不仅存储数据，还包含相应的索引信息。与此相对，全局分区则意味着数据分散于不同的分区，但所有数据的索引却集中存储于单一对象。遗憾的是，MySQL数据库目前尚不具备实现全局分区的功能。

MySQL 查看数据库分区。

展示所有包含“partitions”关键词的变量；

MySQL数据库能够实现多种分区的功能。在表设有主键或唯一索引的情况下，该索引的列必须包含在分区的列之中。在 RANGE、LIST、HASH 以及 KEY 这四种分区方式中，其分区依据要求数据类型必须是整数。若数据并非整数类型，则需借助特定函数将其转换成整数，例如 YEAR 函数、MONTH 函数等。

子分区，即在原有分区的基础上进一步划分，亦称作复合分区。MySQL数据库支持在RANGE和LIST分区之上实施HASH或KEY子分区。完成子分区操作后，分区的总数应为原分区数量与子分区数量相乘的结果。

MySQL数据库支持对NULL值进行分区操作，且将NULL值视为低于所有非NULL值（这与ORDER BY处理NULL值的规则保持一致）。

在运用OLAP（在线分析处理）技术时，分区策略确实能够显著提升查询效率，尤其是考虑到OLAP应用中的多数查询都涉及到对庞大表格的频繁扫描。以一张包含1亿行数据的表格为例，若其中包含一个时间戳属性列，用户在进行基于时间维度的查询时，若采用时间戳进行分区，那么查询只需针对相应的分区进行扫描。

在处理OLTP（在线事务处理）时，通常情况下，我们不会从一张庞大的表中提取超过10%的数据量，大多数情况下，只需通过索引就能获取到少量几条记录。鉴于此，分区策略必须谨慎实施。以一张规模较大的表为例，一般而言，B+树索引仅需进行2至3次I/O操作即可成功检索所需数据。对主键 ID 进行了10次哈希分区处理后，查询操作必须遍历这10个分区，这无疑增加了输入输出的压力。

我们需对数据库分区进行操作，具体步骤为：在表的右键菜单中选择“设计表”，接着进入选项设置，选择“分割区”，此时将展示相关内容。

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

通过 分析数据检索的分区。

解释分区，然后从`t_materiel_config`表中选择所有列。