Mysql 自定义HASH索引带来的巨大性能提升----[挖坑篇]
有这样一个业务场景,需要在2个表里比较存在于A表,不存在于B表的数据。表结构如下:
T_SETTINGS_BACKUP | CREATE TABLE `T_SETTINGS_BACKUP` (
`FID` bigint(20) NOT NULL AUTO_INCREMENT,
`FUSERID` bigint(20) NOT NULL COMMENT '用户ID',
`FDEVICE` varchar(64) NOT NULL DEFAULT '' COMMENT '用户设备号(SN)',
`FAPPID` varchar(64) NOT NULL DEFAULT '' COMMENT '应用ID',
`FKEYID` varchar(32) NOT NULL DEFAULT '' COMMENT '设置项ID',
`FCONTENT` varchar(2000) NOT NULL DEFAULT '' COMMENT '设置项内容',
`FUPDATETIME` datetime NOT NULL DEFAULT '1970-01-01 00:00:00' COMMENT '修改时间',
`FCREATETIME` datetime NOT NULL DEFAULT '1970-01-01 00:00:00' COMMENT '创建时间',
PRIMARY KEY (`FID`),
UNIQUE KEY `UDX_USERID_DEVICE_APPID_KEYID` (`FUSERID`,`FDEVICE`,`FAPPID`,`FKEYID`)
) ENGINE=InnoDB AUTO_INCREMENT=21934 DEFAULT CHARSET=utf8mb4
暂定义上表为A表,记录数:21933
B表表结构如下,记录数:4794959
CREATE TABLE `meizu_device_tmp_1` (
`id` int(11) unsigned NOT NULL DEFAULT '',
`imei` bigint(20) NOT NULL DEFAULT '' COMMENT 'imei',
`sn` varchar(20) CHARACTER SET utf8 NOT NULL DEFAULT '' COMMENT 'sn',
UNIQUE KEY `imei` (`imei`),
UNIQUE KEY `sn` (`sn`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
A的FDEVICE和B的SN是关联字段,现在要求出FDEVICE在A不在B的记录数。自然想到下面的LEFT JOIN
mysql> explain select A.fdevice FROM T_SETTINGS_BACKUP A left JOIN meizu_device_tmp_1 B ON A.FDEVICE=B.sn where B.sn is null;
+----+-------------+-------+-------+---------------+-------------------------------+---------+------+---------+--------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+-------------------------------+---------+------+---------+--------------------------------------+
| 1 | SIMPLE | A | index | NULL | UDX_USERID_DEVICE_APPID_KEYID | 654 | NULL | 22232 | Using index |
| 1 | SIMPLE | B | index | NULL | sn | 62 | NULL | 4772238 | Using where; Using index; Not exists |
+----+-------------+-------+-------+---------------+-------------------------------+---------+------+---------+--------------------------------------+
2 rows in set (0.00 sec)
执行时间1小时以上,等不出结果直接KILL掉了。
分析上面的执行计划,两个表都用到了覆盖索引,每个表都没有过滤条件,所以需要扫描全部行,2W乘以470W是个巨大的数字,执行器在不停的做内循环的判断,直到完成22232*4772238次。除了这个循环次数巨大外,这个执行计划还有2个需要考量的地方
1)type=index 2)key_len
type=index 执行效率仅高于全表扫描,在某些情况下比全部扫描更差。key_len比较大,说明索引太长。A表的索引是个4字段的组合索引,有用的比较字段只有FDEVICE,为了覆盖索引优化器把全部字段都加入判断了。
对于key_len 有两个疑问 1)为什么A表的key_len=654? 2)为什么B表的ken_len=62?
优化key_len, 考虑到业务特性,FUSERID肯定大于0,把SQL改一下,执行计划看起来好一点了,type=range,key_len=8,实际上对A表只用到了FUSERID字段索引,最左前缀,FDEVICE通过WHERE判断。
mysql> desc select A.fdevice FROM T_SETTINGS_BACKUP A left JOIN meizu_device_tmp_1 B ON A.FDEVICE=B.sn where A.fuserid>0 and B.sn is null;
+----+-------------+-------+-------+-------------------------------+-------------------------------+---------+------+---------+--------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+-------------------------------+-------------------------------+---------+------+---------+--------------------------------------+
| 1 | SIMPLE | A | range | UDX_USERID_DEVICE_APPID_KEYID | UDX_USERID_DEVICE_APPID_KEYID | 8 | NULL | 11116 | Using where; Using index |
| 1 | SIMPLE | B | index | NULL | sn | 62 | NULL | 4911049 | Using where; Using index; Not exists |
+----+-------------+-------+-------+-------------------------------+-------------------------------+---------+------+---------+--------------------------------------+
2 rows in set (0.01 sec)
执行时间依旧很长,等不了直接KILL了。
优化到这一步,还有什么别的招数,可以提高执行性能的?似乎已经到了尽头。
回顾下两表的关联字段,A.FDEVICE=B.sn,两个字段都是字符串,在数据类型上考虑,自然想到,是不是可以把记录比较字段从字符串的比较,改成数字的比较?这是个优化的方向。在计算机里底层数据都是01010这样,只需要把数字换算成0101就可以做等值比较了,但是变成字符,需要先去字符编码表找到字符对应的数字,在把数字换算成0101,这里多出一步查找操作。另一方面字符占用的空间比数字要大很多,一个页内能存下的item条目比数字的要少,这会导致更多的数据页读取。
根据这个方向,尝试使用自定义HASH索引,常见的HASH函数有MD5,password,crc32,sha1等,只有crc32哈希之后的值的数字型的。
mysql> select md5('sdsafa'),password('sdsafa'),crc32('sdsafa'),SHA1('sdsafa');
+----------------------------------+-------------------------------------------+-----------------+------------------------------------------+
| md5('sdsafa') | password('sdsafa') | crc32('sdsafa') | SHA1('sdsafa') |
+----------------------------------+-------------------------------------------+-----------------+------------------------------------------+
| c5067032ca64a35620fc5c75aa42265c | *45ABB21DBD1E6A5659E05F1EBAF589A3B39EB835 | 1766538443 | b9349f6a0b8138e3e6461745fd257678eefeb9a2 |
+----------------------------------+-------------------------------------------+-----------------+------------------------------------------+
1 row in set (0.00 sec)
在表里加个字段记录hash之后的值,并对这个字段加上索引。
mysql> CREATE TABLE `meizu_device_tmp_3` (
-> `id` int(11) unsigned NOT NULL DEFAULT '',
-> `imei` bigint(20) NOT NULL DEFAULT '' COMMENT 'imei',
-> `sn` varchar(20) CHARACTER SET utf8 NOT NULL DEFAULT '' COMMENT 'sn',
-> `hash_sn` bigint(20) DEFAULT NULL,
-> UNIQUE KEY `imei` (`imei`),
-> KEY `hash_sn` (`hash_sn`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ;
Query OK, 0 rows affected (0.20 sec) mysql> insert into meizu_device_tmp_3 select id,imei,sn,crc32(sn) from meizu_device_tmp_1;
Query OK, 4794959 rows affected (1 min 50.31 sec)
Records: 4794959 Duplicates: 0 Warnings: 0 mysql> select * from meizu_device_tmp_3 limit 1;
+----------+---------+--------------------+------------+
| id | imei | sn | hash_sn |
+----------+---------+--------------------+------------+
| 23930528 | 1311265 | MX21CA2ALHR2460302 | 2330453935 |
+----------+---------+--------------------+------------+
1 row in set (0.00 sec)
查询时,关联字段先crc32计算后,再比较,这样就变成了数字和数字的比较了,被驱动表比较字段也有索引。
但是crc32算法可能存在hash碰撞,也就是不同的值hash出来的结果是一样的,这就“撞”上了。为了避免碰撞导致的比较结果不准确,在hash比较之后,再做一次原值的比较。
优化之后的查询语句是这样的
mysql> desc select A.fdevice FROM T_SETTINGS_BACKUP A left JOIN meizu_device_tmp_3 B ON crc32(A.FDEVICE)=B.hash_sn and A.fdevice=B.sn where B.sn is null;
+----+-------------+-------+-------+---------------+-------------------------------+---------+------+-------+-------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+-------------------------------+---------+------+-------+-------------------------+
| 1 | SIMPLE | A | index | NULL | UDX_USERID_DEVICE_APPID_KEYID | 654 | NULL | 22232 | Using index |
| 1 | SIMPLE | B | ref | hash_sn | hash_sn | 9 | func | 1 | Using where; Not exists |
+----+-------------+-------+-------+---------------+-------------------------------+---------+------+-------+-------------------------+
2 rows in set (0.00 sec)
巨大的改变,被驱动表的rows=1. SQL执行时间0.38秒。
hash索引有这么大的好处,但是也存在不少缺点
1)hash不能处理范围比较,只能处理等值比较。
2)hash不能做排序,hash出来的结果是随机分布的。
3)hash不支持部分索引,如index a(10)就不支持。
4)hash无法覆盖索引
5)hash有碰撞,碰撞得比较厉害时,处理碰撞的代价就比较高。
CRC32算法:http://wenku.baidu.com/view/465dca06e87101f69e31951f.html
自定义hash索引:http://www.lizhonghaosc.cn/mysql-chuang-jian-zi-ding-yi-ha-xi-suo-yin/
Mysql 自定义HASH索引带来的巨大性能提升----[挖坑篇]的更多相关文章
- Mysql 自定义HASH索引带来的巨大性能提升----[真相篇]
推倒重来 俗话说no zuo no die why you try,这时候我又忍不住zuo了,吭哧吭哧的把解决过程发上博客,向全世界宣布,哥又搞定个难题. 剧情的发展往往是看起来主角完全掌握了局势的情 ...
- Mysql 自定义HASH索引带来的巨大性能提升
有这样一个业务场景,需要在2个表里比较存在于A表,不存在于B表的数据.表结构如下: T_SETTINGS_BACKUP | CREATE TABLE `T_SETTINGS_BACKUP` ( `FI ...
- MySQL 8.0 —— CATS事务调度算法的性能提升
原文地址:https://mysqlserverteam.com/contention-aware-transaction-scheduling-arriving-in-innodb-to-boost ...
- SQL优化系列(三)- 用最少的索引获得最大的性能提升
从全局出发优化索引 对于高负载的数据库,如何创建最少的索引,让数据库的整体性能提高呢?例如,对于100 条SQL语句,如何创建最佳的5条索引? SQL自动优化工具SQL Tuning Expert P ...
- MySQL系列(六)--索引优化
在进行数据库查询的时候,索引是非常重要的,当然前提是达到一定的数据量.索引就像字典一样,通过偏旁部首来快速定位,而不是一页页 的慢慢找. 索引依赖存储引擎层实现,所以支持的索引类型和存储引擎相关,同一 ...
- InnoDB关键特性之自适应hash索引
一.索引的资源消耗分析 1.索引三大特点 1.小:只在一个到多个列建立索引 2.有序:可以快速定位终点 3.有棵树:可以定位起点,树高一般小于等于3 2.索引的资源消耗点 1.树的高度,顺序访问索引的 ...
- 数据库索引------B-Tree 索引和 Hash 索引的对比
对于 B-tree 和 hash 数据结构的理解能够有助于预测不同存储引擎下使用不同索引的查询性能的差异,尤其是那些允许你选择 B-tree 或者 hash 索引的内存存储引擎. B-Tree 索引的 ...
- B-Tree 索引和 Hash 索引的对照
对于 B-tree 和 hash 数据结构的理解可以有助于预測不同存储引擎下使用不同索引的查询性能的差异.尤其是那些同意你选择 B-tree 或者 hash 索引的内存存储引擎. B-Tree 索引的 ...
- Innodb关键特性之自适用Hash索引
一.索引的资源消耗分析 1.索引三大特点 1.小:只在一个到多个列建立索引 2.有序:可以快速定位终点 3.有棵树:可以定位起点,树高一般小于等于3 2.索引的资源消耗点 1.树的高度,顺序访问索引的 ...
随机推荐
- RabbitMq、ActiveMq、ZeroMq 和 kafka 比较
MQ框架非常之多,比较流行的有RabbitMq.ActiveMq.ZeroMq.kafka.这几种MQ到底应该选择哪个?要根据自己项目的业务场景和需求.下面我列出这些MQ之间的对比数据和资料.第一部分 ...
- 用JDBC访问MySQL
/* 在数据库中创建一个Employee的类 create table Employee( id int primary key, name varchar(20), age int); */ imp ...
- 一张图让你看懂各开源License[转]
你是否遇到过开源License,精炼而又晦涩的文字通常要读半天才能理解,而且大多数License差别不大,容易混淆.下面这张图让你段时间迅速掌握各种开源的License. 图片来源:阮一峰的博客. f ...
- Rhel6-mysql_cluster配置文档
MySQL Cluster 是一种技术,其主要功能是在无共享的相关系统中部署内存中数据库 的 Cluster .在通过无共享体系结构,系统能够使用廉价的硬件,而且对软硬件无特殊要求. 此外,由于每个组 ...
- php常量的声明和使用
(1)声明 define("var",value) (2)先声明后使用 (3)默认区分大小写,如要不区分 define ("var",value,true); ...
- 使用UISegmentedControl的一个注意事项
NSArray* array = [[NSArray alloc]initWithObjects:@"机会",@"联系人", nil]; //先确定segmen ...
- AngularJs的UI组件ui-Bootstrap分享(二)——Collapse
Collapse折叠控件使用uib-collapse指令 <!DOCTYPE html> <html ng-app="ui.bootstrap.demo" xml ...
- MyJni撒旦
package com.baidu.jnitest; import android.os.Bundle; import android.app.Activity; import android.vie ...
- 关于uboot和kernel的一些理解
经过多次的修改和实验,终于能够在mini2440开发板上进行各种uboot和kernel的挂载实验了,在此期间学习到了很多知识,也理解了一些知识1->分区uboot和kernel的分区表要一致u ...
- C#之属性
在C#类中有属性这个成员,C#属性用来读写类的字段.实际上是通过get和set访问器实现的.