未加星标

What is the default sharding key in MySQL Cluster?

字体大小 | |
[数据库(mysql) 所属分类 数据库(mysql) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

mysql Cluster does an automatic sharding/partitioning to the tables across data nodes, enabling databases to scale horizontally to serve read and write-intensive workloads, but what is the default sharding key used in partitioning the data?

According to the recent update (Oct, 2016) of the MySQL Cluster white paper , primary key is the default sharding key:

By default, sharding is based on hashing of the primary key , which generally leads to a more even distribution of data and queries across the cluster than alternative approaches such as range partitioning.

However, that is not the case in all MySQL Cluster versions so far!

In this post, I’ll do some test cases on MySQL Cluster (of 4 datanodes) to confirm the default sharding key.

Testing on MySQL Cluster 7.2.26

Creating a simple table of one column (as primary key), insert a single value in that table and check which partition(s) will be used to retrieve that value:

mysql> CREATE TABLE shard_check_pk (id int(11) primary key) engine=ndbcluster;
Query OK, 0 rows affected (0.38 sec)
mysql> INSERT INTO shard_check_pk values (1);
Query OK, 1 row affected (0.01 sec)
mysql> EXPLAIN PARTITIONS SELECT * FROM shard_check_pk WHERE id=1;
+----+-------------+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
| 1 | SIMPLE | shard_check | p3 | eq_ref | PRIMARY | PRIMARY | 4 | const | 1 | |
+----+-------------+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)

If the PK is the sharding key, then a PK value lookup will be checked inonly one partition and according to the previous explain output that was the case already in this example, a single id value (id=1) does only require scanningone partition, ” p3 ”.

What is the case then if we didn’t specify a PK for a table in MySQL Cluster?

mysql&gt; CREATE TABLE shard_check_no_pk (id int(11)) engine=ndbcluster;<br /> Query OK, 0 rows affected (0.19 sec)<br /> mysql&gt; INSERT INTO shard_check_no_pk values (1);<br /> Query OK, 1 row affected (0.00 sec)<br /> mysql&gt; EXPLAIN PARTITIONS SELECT * FROM shard_check_no_pk WHERE id=1;<br /> +----+-------------+-------+-------------+------+---------------+------+---------+------+------+-----------------------------------+<br /> | id | select_type | table | <strong>partitions</strong> | type | possible_keys | key | key_len | ref | rows | Extra |<br /> +----+-------------+-------+-------------+------+---------------+------+---------+------+------+-----------------------------------+<br /> | 1 | SIMPLE | shard_check_no_pk | <strong>p0,p1,p2,p3</strong> | ALL | NULL | NULL | NULL | NULL | 2 | Using where with pushed condition |<br /> +----+-------------+-------+-------------+------+---------------+------+---------+------+------+-----------------------------------+<br /> 1 row in set (0.00 sec)

As we can see in the previous explain plan, all partitions in the table (p0, p1, p2 & p3) will be scanned to retrieve a single id value (id=1). The reason for that is because MySQL Cluster creates a hidden column to be the sharding key on tables without PKs.

Up to here, the results are as expected but in the latter MySQL Cluster versions (7.3, 7.4 and 7.5), that is not the case!

Testing on MySQL Cluster 7.5.4 (same results on 7.3 and 7.4):

mysql&gt; CREATE TABLE shard_check_pk (id int(11) <strong>primary key</strong>) engine=ndbcluster;<br /> Query OK, 0 rows affected (0.38 sec)<br /> mysql&gt; INSERT INTO shard_check_pk values (1);<br /> Query OK, 1 row affected (0.01 sec)<br /> mysql&gt; EXPLAIN SELECT * FROM shard_check_pk WHERE id=1;<br /> +----+-------------+-------------+-------------+--------+---------------+---------+---------+-------+------+----------+-------+<br /> | id | select_type | table | <strong>partitions</strong> | type | possible_keys | key | key_len | ref | rows | filtered | Extra |<br /> +----+-------------+-------------+-------------+--------+---------------+---------+---------+-------+------+----------+-------+<br /> | 1 | SIMPLE | shard_check_pk | <strong>p0,p1,p2,p3</strong> | eq_ref | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | NULL |<br /> +----+-------------+-------------+-------------+--------+---------------+---------+---------+-------+------+----------+-------+<br /> 1 row in set, 1 warning (0.00 sec)

Starting from MySQL Cluster 7.3, the hidden column is always used as the default sharding key even on a table that has a PK!

I filed a bug report ( Bug #84374) aboutthis case and until getting it fixed, one can override this behavior by specifying the sharding key explicitly:

mysql&gt; ALTER TABLE shard_check_pk PARTITION BY KEY (`id`);<br /> Query OK, 1 row affected (1.10 sec)<br /> Records: 1 Duplicates: 0 Warnings: 0<br /> mysql&gt; EXPLAIN SELECT * FROM shard_check_pk WHERE id=1;<br /> +----+-------------+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------+<br /> | id | select_type | table | <strong>partitions</strong> | type | possible_keys | key | key_len | ref | rows | filtered | Extra |<br /> +----+-------------+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------+<br /> | 1 | SIMPLE | shard_check_pk | <strong>p3</strong> | eq_ref | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | NULL |<br /> +----+-------------+-------------+------------+--------+---------------+---------+---------+-------+------+----------+-------+<br /> 1 row in set, 1 warning (0.00 sec)

Conclusion: Primary key is the default sharding key in MySQL Cluster 7.2 and a hidden column will be used if no PKs defined for a table. Until the bug got fixed and starting from MySQL Cluster 7.3, the hidden column is always the default sharding key even on a table that has a PK!

本文数据库(mysql)相关术语:navicat for mysql mysql workbench mysql数据库 mysql 存储过程 mysql安装图解 mysql教程 mysql 管理工具

主题: SQLMySQLRIMTIRY
分页:12
转载请注明
本文标题:What is the default sharding key in MySQL Cluster?
本站链接:http://www.codesec.net/view/522831.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(mysql) | 评论(0) | 阅读(98)