文章图片
提到分区表,一般按照范围(range)来对数据拆分居多,以哈希来对数据拆分的场景相来说有一定局限性,不具备标准化。接下来我用几个示例来讲讲 MySQL 哈希分区表的使用场景以及相关改造点。
对于哈希分区表,最通俗的方法就是 hash 单个字段,比如下面表 hash_t1(存有500W行记录),按照自增 ID 来做 HASH ,分区数目为 1024 :
mysql:ytt_new> show create table hash_t1\G
*************************** 1. row ***************************
Table: hash_t1
Create Table: CREATE TABLE `hash_t1` (
`id` bigint unsigned NOT NULL AUTO_INCREMENT,
`r1` int DEFAULT NULL,
`log_date` date DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!50100 PARTITION BY HASH (`id`)
PARTITIONS 1024 */
1 row in set (0.00 sec)mysql:ytt_new> select count(*) from hash_t1;
+----------+
| count(*) |
+----------+
|5000000 |
+----------+
1 row in set (2.43 sec)
表 hash_t1 的分区方式很好理解,按照 ID 来对数据进行 HASH 拆分,也就是按照分区数量求模, 类似于 hash(mod(id,1024)) ,数据分布非常均匀。
mysql:ytt_new> select max(table_rows),min(table_rows) from information_schema.partitions where table_name = 'hash_t1';
+-----------------+-----------------+
| max(table_rows) | min(table_rows) |
+-----------------+-----------------+
|4883 |4882 |
+-----------------+-----------------+
1 row in set (0.04 sec)
接下来考虑以下几条 SQL 语句:
SQL 1:select count(*) from hash_t1 where id = 1;
SQL 2:select count(*) from hash_t1 where id in (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15);
SQL 3:select count(*) from hash_t1 whereid <=1;SQL 4:select count(*) from hash_t1 where id <=15;
SQL 1 和 SQL 2 非常适合检索哈希分区表,SQL 3 和 SQL 4 就不太适合。
SQL 1 的执行计划:对于哈希分区表来说为最优场景,能具体到某单个分区,过滤值为常量。
mysql:ytt_new> explain select count(*) from hash_t1 where id = 8\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: hash_t1
partitions: p8
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: const
rows: 1
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.00 sec)
SQL 2 针对字段 ID 的过滤条件为15个常量组合,具体到15个分区,对比总分区数来讲比例很小,也很优化。不过从执行计划来看,还有优化空间,可以考虑改变分区表的哈希方式,后面介绍。
SQL 2 的执行计划:
mysql:ytt_new> explain select count(*) from hash_t1 where idin (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: hash_t1
partitions: p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 15
filtered: 100.00
Extra: Using where;
Using index
1 row in set, 1 warning (0.00 sec)
SQL 3 、SQL 4 与 SQL 1 、SQL 2 实现的效果一样,不过却要扫描所有分区才能拿到结果。
来同样看下 SQL 3 执行计划:
mysql:ytt_new> explain select count(*) from hash_t1 whereid <=1\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: hash_t1
partitions: p0,p1,p2,...,p1021,p1022,p1023
...
所以需要注意的是哈希分区表仅限于等值过滤检索,类似对普通表基于哈希索引的检索。
之前我们有看到 SQL 2 扫描了不必要的分区, 那能否减少 SQL 2 扫描的分区数量呢?答案是可以的。
得重新对表数据进行哈希拆分,由需求到定义反着来:
创建一张新表 hash_t2 , 按照 Id div 1024 来分区,每个分区就能严格按照 ID 顺序存放前 1024 个值:
mysql:ytt_new> create table hash_t2 (id bigint unsigned auto_increment primary key, r1 int, log_date date) partition by hash(id div 1024) partitions 1024;
Query OK, 0 rows affected (10.54 sec)mysql:ytt_new>load data infile '/var/lib/mysql-files/hash_sample.csv' into table hash_t2;
Query OK, 5000000 rows affected (3 min 20.11 sec)
Records: 5000000Deleted: 0Skipped: 0Warnings: 0
来看看效果:此时 SQL 2 可以基于单个分区 p0 来检索数据。
mysql:ytt_new> explain select count(*) from hash_t2 where id in (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: hash_t2
partitions: p0
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 15
filtered: 100.00
Extra: Using where;
Using index
1 row in set, 1 warning (0.00 sec)
此外,哈希分区还适合特定的日期类等值查询场景, 分区定义比按照范围要简单,实现效果一样。比如按照日期来检索的 SQL 5 :
SQL 5: select count(*) from hash_t1 where log_date= '2020-08-05';
创建新表 hash_t3 ,分区字段为 year(log_date) :
mysql:ytt_new>create table hash_t3 (id bigint unsigned , r1 int,log_date date, key idx_log_date(log_date));
Query OK, 0 rows affected (0.04 sec)mysql:ytt_new>alter table hash_t3 partition by hash(year(log_date)) partitions 11;
Query OK, 0 rows affected (0.32 sec)
Records: 0Duplicates: 0Warnings: 0mysql:ytt_new>load data infile '/var/lib/mysql-files/hash_sample.csv' into table hash_t3;
Query OK, 5000000 rows affected (2 min 4.59 sec)
Records: 5000000Deleted: 0Skipped: 0Warnings: 0
定义好新表,来看下 SQL 5 的执行计划: 基于日期的检索也能限定在单个分区。
mysql:ytt_new>explainselect count(*) from hash_t3 where log_date = '2020-08-05'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: hash_t3
partitions: p7
type: r
possible_keys: idx_log_date
key: idx_log_date
key_len: 4
ref: const
rows: 1405
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.00 sec)
这里用 year 还不够优化,后期随着数据量增加,每个分区的数据会有增长,可以考虑按照 month 来拆分数据。
【第41期(MySQL 哈希分区表)】MySQL 还有一个特殊的哈希分区:不限制输入数据类型的KEY 分区,哈希函数预定义为系统函数 PASSWORD ,定义更加简单,适合主键非整型字段的表。
以上这些都只是考虑查询性能,如果后期分区经常扩容,缩容等,可以考虑线性哈希分区。
线性哈希是一致性哈希在 MySQL 里的具体实现,其目的就是为了解决分区表后期扩缩容性能问题。不过会带来分区数据分布不均匀、出现数据热点、相同 SQL 扫描记录数被放大等新问题。
用一个简单例子来对比下两者的差异:把表 hash_t1 分区数量缩减到10个,总花费时间2分钟46秒:
mysql:ytt_new>alter table hash_t1 coalesce partition 1014;
Query OK, 0 rows affected (2 min 46.01 sec)
Records: 0Duplicates: 0Warnings: 0
新建线性哈希表 hash_linear_t1 ,初始分区数目也是 1024 ,同样把分区数目减少到10个。 缩减分区的时间为1分钟28秒,比操作表 hash_t1 时间上少了一半左右。
mysql:ytt_new>create table hash_linear_t1 (id bigint unsigned auto_increment primary key, r1 int,log_date date) partition by linear hash(id) partitions 1024;
Query OK, 0 rows affected (34.13 sec)mysql:ytt_new>load data infile '/var/lib/mysql-files/hash_sample.csv' into table hash_linear_t1 ;
Query OK, 5000000 rows affected (2 min 7.78 sec)
Records: 5000000Deleted: 0Skipped: 0Warnings: 0mysql:ytt_new>alter table hash_linear_t1 coalesce partition 1014;
Query OK, 0 rows affected (1 min 28.29 sec)
Records: 0Duplicates: 0Warnings: 0
来看下两张分区表的数据分布情况:很明显,线性哈希表数据分布不是很均匀,存在严重的数据热点问题。
mysql:ytt_new>select table_rows from information_schema.partitions where table_name = 'hash_t1';
+------------+
| TABLE_ROWS |
+------------+
|485723 |
|537704 |
|523017 |
|470724 |
|478982 |
|512272 |
|483190 |
|455829 |
|520512 |
|461572 |
+------------+
10 rows in set (0.00 sec)mysql:ytt_new>select table_rows from information_schema.partitions where table_name = 'hash_linear_t1 ';
+------------+
| TABLE_ROWS |
+------------+
|269443 |
|340989 |
|611739 |
|584321 |
|566181 |
|624040 |
|637801 |
|688467 |
|331397 |
|317695 |
+------------+
10 rows in set (0.01 sec)
本篇介绍了 MySQL 哈希分区表的使用场景以及一些细微差异。切记:哈希分区不能用于范围查询,只能用作等值查询场景。
推荐阅读
- VUE|Flask+VUE 实现页面增删改查显示开发+测试(图文教程附源码)
- linux|linux部署web项目
- 工具使用|Linux环境下部署web项目详细步骤——CentOS7
- 职场|第109个母亲节快乐,程序猿特殊的表达
- Learning|MySQL数据库使用小皮系统(phpstudy)的安装及配置流程
- java|美团配送 二面(40min) Java后端 暑期实习面经
- 史上最全的MySQL面试题和答案大汇总
- Linux|Linux安装MySQL5.7(使用rpm安装)
- pytest框架|软件测试面试题(写出5个Loadrunner中常用函数,并对其中2个举例说明用法)