（十二）MariaDB中的分区操作

Posted 2023-05-03

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了（十二）MariaDB中的分区操作相关的知识，希望对你有一定的参考价值。

参考技术A

数据量不大的中小型规模 size 的 Table 原则是还是采用 Table+Index 设计为最佳化的思考重点。

在大数据考虑数据分片的时候，有两点也是重点：

一是空间，数据存放的存储空间是否足够，易于扩展。
二是时间，对于数据存取是否有限制，能否优化。

此外就是：

对于 MyISAM 引擎，可以设计分离数据文件和索引文件来加快数据存取。例如：

当然，InnoDB 采用 System TableSpace 集中存放,无法支持此种方式，需要通过设定去转换成一个 table 一个 file。

MariaDB 10 提供 Table 分区储存功能，大量数据切割成不同储存区域(Partition)，Partiton 底层的档案可再切成多档方式储存(Sub-Partition)。

使用 Plugin 方式扩充

由 Storage Engine 自行实作，MariaDB 已支持的包括 InnoDB, TokuDB , Memory, Aria, Spider、MyISAM, Archive, BLACKHOLE

mysql 仅支援 InnoDB

MariaDB 透过内建的 Partiton Storage Engine 提供此项分区服务 。

查看是否有安装此引擎：

系统管理方式与一般 tables 相同,System Partition 提供元数据（Metadata）: Informaton_Schema.PARTITIONS 。

分区作业时，有些东西还需要特别考虑，例如分区类型、分区计算、目标表的形态、分区前后的应用等等。

MariaDB 的分区类型主要有：

语法：

CREATE TABLE 语句的最后一部分可以是新表分区的定义。对于 RANGE 分区

说明：

示例：

通过年份对日志表进行分区

注意：

如果 partitioning_expression 表达式引用的字段不是，就会出现以下错误：

语法：

说明：

示例：

依据文章语言分类，所有可能的筛选值必须判断，Language 事实上是 Foreign key 对应到 Language Table（所以用 id 表示），Partition table 不支持 Fkey，Language 必须是正整数或 null。

字段型别:
Integer ( 不可产生负数 )、Date, DateTime、CHAR, VARCHAR, BINARY , VARBINARY、不可使用任何 functions, 运算子符号 (只能单纯使用字段…)

语法：

RANGE COLUMNS 分区类型：

LIST COLUMNS 分区类型：

两者的区别：

RANGE COLUMNS 是返回的值小于指定的值，第一个匹配条件的分区将包含该值；
LIST COLUMNS 返回的值包含在给定的值里面，同样允许且仅运行一个 DEFAULT 分区。

示例，修改上述 article 表，新加 year 字段：

分割后的 Table 将产生多个个别档案

文件名编码: table_name#P#partition_name.ext

在 InnoDB 下，会有以下 3 类:

以之前的 article 表为例，回顾一下创建语言：

使用 EXPLAIN PARTITIONS 来查看哪些分区会被使用到：

从结果来看，的确在 WHERE language < 4; 的条件下，只有 p0 和 p1 分区会有访问到。

如果优化器不知道或无法推断出哪些分区会被使用到，可以通过 PARTITION 子句强制 MariaDB 仅访问给定分区(MariaDB 10.0 开始)，这也被称为 分区选择 。

例如：

所有 DML 语句均支持 PARTITION 子句：SELECT、INSERT、UPDATE、DELETE、REPLACE、LOAD DATA 等。

通常情况下，分区修剪会用在触发器(triggers)语句中。

但是如果在表上定义了 BEFORE INSERT 或者 BEFORE UPDATE 的触发器，则 MariaDB 不会预先知道分区表达式中使用的字段(column)是否会更改。因此，被迫锁定所有分区。

MariaDB Spider蜘蛛侠轻松解决表的横纵向扩展

什么是Spider？

当您的数据库不断增长时，您绝对需要考虑其他技术，如数据库分片。Spider是MariaDB内置的一个可插拔用于MariaDB/MySQL数据库分片的存储引擎，充当应用服务器和远程后端DB之间的代理（中间件），它可以轻松实现MySQL的横向和纵向扩展，突破单台MySQL的限制，支持范围分区、列表分区、哈希分区，支持XA分布式事务，支持跨库join。通过Spider，您可以跨多个数据库后端有效访问数据，让您的应用程序一行代码不改，即可轻松实现分库分表！

分库分表架构图：

应用程序连接Spider，Spider充当中间件代理，将客户端查询的请求，按照事先定义好的分片规则，分发给后端数据库，之后返回的数据汇总在Spider内存里做聚合，最终返回客户端请求，对于应用程序而言是透明的。

分片字段的选取：

一定要针对业务上查询最频繁的字段做片键，查询时会直接路由到后端DB上，否则会轮训遍历后端所有DB，跨多个网络性能就会下降。

1、范围分片的优点是无限扩容，但缺点是冷热数据不均匀。

2、HASH分片解决了冷热数据不均匀的问题，但今后扩容比较麻烦，比如之前对表取模了128张，今后变更为256张，数据要重新导入。

典型案例---腾讯游戏

腾讯游戏的生产环境数据量达到了100TB，用了396个Spider节点做数据拆分，分片后的数据用了2800个MySQL节点存储。

使用场景介绍

下面我介绍一下我负责的一个项目，通过Spider实现了历史表的垂直拆分的经验分享。随着业务的增长，单台服务器磁盘空间有限，有些业务上的历史数据，DBA用工具pt-archiver归档后，历史表就没有用了，通常我们会把他单独迁移到备份机，主库上就删除了。但有的时候，BI统计部门来了一个需求，需要临时关联查询这些历史表，那么DBA需要从备份机上myloader导入到从库上去，为了降低导数据引起的从库CPU升高、磁盘IO的瞬间增大，可能造成主从复制的延迟，为了减少这种重复性的体力工作，为了更快速的缩短可用时间，我们可以通过Spider引擎解决，通过它你可以将远程服务器上的表做一个映射，做一个软连接，相当于你操作本地的表一样，简单而便捷，省去了那么多麻烦，临时提供给业务方用，你也不用考虑啥性能问题。

架构图如下：

实施这个方案，选择Spider引擎是有优势的：SQL解析和查询优化是个非常复杂而且很难做好的工作，其他替代产品都是自己实现，由于复杂性，这些产品都带来了一些限，比如不支持存储过程、函数、视图等，给使用和实施带来了困难。而作为一个存储引擎，这些工作都由MariaDB自身完成了，可以方便的将大表做分布式拆分，和Fabric相比，它的好处是对业务方使用是透明的，SQL语法没有任何限制，在不改变现有DB架构的方案中，侵入性最小。

内部原理架构图如下：