标签：content utf8 key 索引 hash函数 join sql 通过 settings
有这样一个业务场景，需要在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 ‘0‘, `imei` bigint(20) NOT NULL DEFAULT ‘0‘ 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 | +----+-------------+-------+-------+---------------+-------------------------------+---------+------+---------+--------------------------------------+ 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 | +----+-------------+-------+-------+-------------------------------+-------------------------------+---------+------+---------+--------------------------------------+ 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 | +----------------------------------+-------------------------------------------+-----------------+------------------------------------------+ row in set (0.00 sec)
在表里加个字段记录ｈａｓｈ之后的值，并对这个字段加上索引。
mysql> CREATE TABLE `meizu_device_tmp_3` (
-> `id` int(11) unsigned NOT NULL DEFAULT ‘0‘,
-> `imei` bigint(20) NOT NULL DEFAULT ‘0‘ 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 |
+----------+---------+--------------------+------------+
row in set (0.00 sec)
查询时，关联字段先crc32计算后，再比较，这样就变成了数字和数字的比较了，被驱动表比较字段也有索引。
但是crc32算法可能存在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 | +----+-------------+-------+-------+---------------+-------------------------------+---------+------+-------+-------------------------+ 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有碰撞，碰撞得比较厉害时，处理碰撞的代价就比较高。
标签：content utf8 key 索引 hash函数 join sql 通过 settings
原文地址：https://www.cnblogs.com/jack-Star/p/9413192.html
