MySQL表中存储UUID值作为主键,使用UNHEX()提升性能

假设我们有一个用户表,每个用户都有一个UUID。MySQL有一个UUID()函数,它使MySQL生成一个UUID值,并以VARCHAR(36)类型的可读形式返回。让我们试试MySQL 5.7.8:


mysql> select uuid();
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| aab5d5fd-70c1-11e5-a4fb-b026b977eb28 |
+--------------------------------------+

mysql> select uuid();
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| aab5d5fd-70c1-11e5-a4fb-b026b977eb28 |
+--------------------------------------+
所以第一个想法是简单地做到这一点:




create table users(id varchar(36), name varchar(200));
insert into users values(uuid(), 'Andromeda');

create table users(id varchar(36), name varchar(200));
insert into users values(uuid(), 'Andromeda');
但是这种UUID的可读形式并不紧凑。让我们观察一下:


四个破折号是多余的
每对字符实际上是一个在00-FF范围内的十六进制数; 总共有16个数字(以上为:0xAA,0xB5等),每个数字可以存储在一个字节中。
所以我们可以使用REPLACE()去掉破折号,UNHEX()把每个
双字符对转换成一个字节:


create table users(id_bin binary(16), name varchar(200));
insert into users values(unhex(replace(uuid(),'-','')), 'Andromeda');

create table users(id_bin binary(16), name varchar(200));
insert into users values(unhex(replace(uuid(),'-','')), 'Andromeda');
这个二进制形式使用16个字节,比人类可读形式(我现在称之为“文本”形式)使用的VARCHAR(36)小得多。如果UUID必须是主键,则增益更大,如InnoDB中的主键值被复制到所有二级索引值中。


二进制(16)是...好吧...只是二进制!没有字符集,没有排序,只有十六个字节。适合我们的需求。


也许在某些应用程序中,文本形式仍然是必需的,所以让我们把它作为表格中的一个附加列; 但为了尽量减少磁盘占用,让我们将文本形成一个虚拟的生成 列(这是MySQL 5.7的一个新特性,在CREATE TABLE的文档中有描述)。该列将通过二进制格式列的公式计算:我们将二进制格式转换回十六进制数字并插入破折号。




create table users(
id_bin binary(16),
id_text varchar(36) generated always as
 (insert(
    insert(
      insert(
        insert(hex(id_bin),9,0,'-'),
        14,0,'-'),
      19,0,'-'),
    24,0,'-')
 ) virtual,
name varchar(200));


insert into users (id_bin,name)
  values(unhex(replace(uuid(),'-','')), 'Andromeda');


select id_text, name from users;
+--------------------------------------+-----------+
| id_text                              | name      |
+--------------------------------------+-----------+
| C2770D2E-70E6-11E5-A4FB-B026B977EB28 | Andromeda |
+--------------------------------------+-----------+

create table users(
id_bin binary(16),
id_text varchar(36) generated always as
 (insert(
    insert(
      insert(
        insert(hex(id_bin),9,0,'-'),
        14,0,'-'),
      19,0,'-'),
    24,0,'-')
 ) virtual,
name varchar(200));
 
insert into users (id_bin,name)
  values(unhex(replace(uuid(),'-','')), 'Andromeda');
 
select id_text, name from users;
+--------------------------------------+-----------+
| id_text                              | name      |
+--------------------------------------+-----------+
| C2770D2E-70E6-11E5-A4FB-B026B977EB28 | Andromeda |
+--------------------------------------+-----------+
我没有在SELECT中包含id_bin,因为它会以隐藏字符(ASCII码0xC2,0x77等:通常不在人可读的字符范围内)出现。我们没有理由需要看id_bin的内容; 但是,如果这样做,则可以使用HEX(id_bin)来显示其十六进制代码。


请注意,id_text被声明为VIRTUAL,因此在磁盘上的表中不占用空间。


使id_text成为生成列的另一个好处是消除了两列之间的任何不一致的风险。事实上,如果id_text是一个简单的列,可以做




update users set id_bin = <something>;

而无意更新id_text。但是作为一个生成的列,id_text不能直接更新,而是在更新id_bin时自动更新。换句话说,信息只在一个地方(id_bin),数据库保证了一致性。


那么,那么查询呢?例如,我们可能想通过UUID找到一个用户:



select * from users where <it has UUID XYZ>;

WHERE子句应该指定二进制还是文本形式?这取决于:


如果我们创建一个二进制形式的索引:


alter table users add unique(id_bin);


那么,为了使用这个索引,WHERE应该指定二进制形式:


WHERE id_bin = binary_form_of_XYZ


相反,如果我们在文本表单上创建一个索引:


alter table users add unique(id_text);



那么,WHERE应该指定文本形式:


WHERE id_text = text_form_of_XYZ

即使id_text是一个虚拟列,也可以像上面那样在其上添加索引(在这种情况下,索引占用磁盘空间)。这是MySQL 5.7.8中引入的一个新功能。


但是,如果我们有一个选择,由于二进制形式更短,它索引它看起来更合乎逻辑,而不是文本形式 - 索引将更小,从而更快地遍历,更快的备份...


最后,还有如何巧妙地重新排列二进制形式的字节的问题。


要了解这一点,我们需要了解更多关于UUID的信息。它们存在几个版本,不同的来源可以生成不同的版本。MySQL的UUID()使用版本1,这意味着,正如在RFC 4.1.2中所解释的那样,三个最左边的以破折号分隔的组是8字节的时间戳:最左边的组是时间戳的低四个字节; 第二组是中间两个字节,第三个组是高(最重要)两个字节的时间戳。因此,最左边的组变化最快(每微秒10次)。我们可以验证:




mysql> select uuid(); do sleep(2); select uuid();
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| 3b96402f-70c5-11e5-a4fb-b026b977eb28 |
+--------------------------------------+
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| 3cc7f7dc-70c5-11e5-a4fb-b026b977eb28 |
+--------------------------------------+

mysql> select uuid(); do sleep(2); select uuid();
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| 3b96402f-70c5-11e5-a4fb-b026b977eb28 |
+--------------------------------------+
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| 3cc7f7dc-70c5-11e5-a4fb-b026b977eb28 |
+--------------------------------------+
你可以看到最左边的8个字符是如何变化的,而其他的则没有。


因此,在由单个机器连续产生的UUID序列中,所有UUID具有不同的第一字节。将该序列插入索引列(二进制或文本形式)将因此每次修改不同的索引页面,从而防止内存中的缓存。因此,在我们存储到id_bin之前,重新安排UUID,使得快速变化的部分走到最后,是有意义的。再一次请注意,这个想法只适用于版本1的UUID。


这个想法不是我的 ; 我在第一次看到它这个博客(http://mysql.rjweb.org/doc.php/uuid)和那一个(https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/)。


以下,通过改变时间低/时间中/时间高到时间高/时间中/时间低来重新排列二进制形式。




create table users(id_bin binary(16), name varchar(200));


set @u = unhex(replace(uuid(),'-',''));


insert into users (id_bin,name)
values
(
 concat(substr(@u, 7, 2), substr(@u, 5, 2),
        substr(@u, 1, 4), substr(@u, 9, 8)),
 'Andromeda'
);

create table users(id_bin binary(16), name varchar(200));
 
set @u = unhex(replace(uuid(),'-',''));
 
insert into users (id_bin,name)
values
(
 concat(substr(@u, 7, 2), substr(@u, 5, 2),
        substr(@u, 1, 4), substr(@u, 9, 8)),
 'Andromeda'
);
我在(@u)之上使用了一个用户变量,因为每个SUBSTR()调用需要引用UUID值,但是我不能写UUID()四次:每次都会生成一个新的UUID!所以我调用一次UUID(),删除破折号,将其转换为二进制文件,将其存储在一个变量,并做它的四个SUBSTR。


但是,我仍然希望文本格式处于“未重新排列”的顺序,因为...或许这个文本格式将用于一些错误日志记录,调试?如果人类要阅读它,我不想通过重新排列的顺序来混淆它们。
添加id_text可以在CREATE TABLE中完成,或者作为后续的ALTER TABLE:




alter table users add
id_text varchar(36) generated always as
(
 insert(
   insert(
     insert(
       insert(
         hex(
           concat(substr(id_bin,5,4),substr(id_bin,3,2),
                  substr(id_bin,1,2),substr(id_bin,9,8))
         ),
         9,0,'-'),
     14,0,'-'),
   19,0,'-'),
 24,0,'-')
) virtual;

alter table users add
id_text varchar(36) generated always as
(
 insert(
   insert(
     insert(
       insert(
         hex(
           concat(substr(id_bin,5,4),substr(id_bin,3,2),
                  substr(id_bin,1,2),substr(id_bin,9,8))
         ),
         9,0,'-'),
     14,0,'-'),
   19,0,'-'),
 24,0,'-')
) virtual;
它将二进制形式的部分(带有SUBSTR)放在“正常”位置(CONCAT),将字节转换为十六进制数字(HEX)并插入破折号。对,这是一个复杂的表达式,但是在创建生成的列时只能输入一次。


现在看看数据:



select id_bin, hex(id_bin), name, id_text from users;
+------------------+----------------------------------+-----------+--------------------------------------+
| id_bin           | hex(id_bin)                      | name      | id_text                              |
+------------------+----------------------------------+-----------+--------------------------------------+
| �p�:�ˤ� &�w�        | 11E570EA3A059CCBA4FBB026B977EB28 | Andromeda | 3A059CCB-70EA-11E5-A4FB-B026B977EB28 |
+------------------+----------------------------------+-----------+--------------------------------------+

select id_bin, hex(id_bin), name, id_text from users;
+------------------+----------------------------------+-----------+--------------------------------------+
| id_bin           | hex(id_bin)                      | name      | id_text                              |
+------------------+----------------------------------+-----------+--------------------------------------+
| �p�:�ˤ� &�w�        | 11E570EA3A059CCBA4FBB026B977EB28 | Andromeda | 3A059CCB-70EA-11E5-A4FB-B026B977EB28 |

+------------------+----------------------------------+-----------+--------------------------------------+

专栏是:
1.隐含字符(重新排列的二进制UUID)
2.第一列的相应的十六进制代码
3.名字
4.未重新排列的文本UUID。看看这个文本形式最左边的3A059CCB是如何快速变化的部分,处于二进制形式(第2列)的中间,所以二进制形式将会提供更有效的索引。

java中使用UUID.randomUUID().toString().replace("-", "").toLowerCase()来生成UUID。

猜你喜欢

转载自www.cnblogs.com/caiguaismine/p/10080044.html