通過(guò)實(shí)例認(rèn)識(shí)MySQL中前綴索引的用法

更新時(shí)間：2015年05月08日 09:50:51 作者：羅龍九

這篇文章主要通過(guò)實(shí)例來(lái)介紹MySQL中的前綴索引,包括前綴在實(shí)際使用中需要考慮到的長(zhǎng)度問(wèn)題等,需要的朋友可以參考下

今天在測(cè)試環(huán)境中加一個(gè)索引時(shí)候發(fā)現(xiàn)一警告

root@test 07:57:52>alter table article drop index ind_article_url;
Query OK, 144384 rows affected (16.29 sec)
Records: 144384 Duplicates: 0 Warnings: 0
root@test 07:58:40>alter table article add index ind_article_url(url);
Query OK, 144384 rows affected, 1 warning (19.52 sec)
Records: 144384 Duplicates: 0 Warnings: 0
root@test 07:59:23>show warnings;
+———+——+———————————————————+
| Level  | Code | Message                         |
+———+——+———————————————————+
| Warning | 1071 | Specified key was too long; max key length is 767 bytes |
+———+——+———————————————————+
1 row in set (0.00 sec)

用show create table article查看索引以及表結(jié)構(gòu)的信息：

`URL` varchar(512) default NULL COMMENT ‘外鏈url',
……
KEY `ind_article_url` (`URL`(383))
…..
DEFAULT CHARSET=gbk
……
drop table test;
create table test(test varchar(767) primary key)charset=latin5;

– 成功
接下來(lái)未測(cè)試，在不同的字符集：

drop table test;
create table test(test varchar(768) primary key)charset=latin5;

– 錯(cuò)誤
–

ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes
drop table test;
create table test(test varchar(383) primary key)charset=GBK;

– 成功

drop table test;
create table test(test varchar(384) primary key)charset=GBK;

– 錯(cuò)誤
–

 ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes
drop table test;
create table test(test varchar(255) primary key)charset=UTF8;

– 成功

drop table test;
create table test(test varchar(256) primary key)charset=UTF8;

– 錯(cuò)誤
–

ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

MySQL的varchar索引只支持不超過(guò)768個(gè)字節(jié) 或者 768/2=384個(gè)雙字節(jié) 或者 768/3=256個(gè)三字節(jié)的字段
而 GBK是雙字節(jié)的，UTF-8是三字節(jié)的。
那么上面出現(xiàn)的原因就明了，我的字符集是為GBK為雙字節(jié)，而url為512個(gè)字符，1024個(gè)字節(jié)，所以超過(guò)字符串索引的限制，報(bào)出了警告，mysql默認(rèn)創(chuàng)建了383（766字節(jié)）長(zhǎng)度的前綴索引。
我們知道小的索引大小不僅對(duì)空間存儲(chǔ)，內(nèi)存的降低和性能的提升有重大作用，那么在計(jì)算前綴索引的長(zhǎng)度的時(shí)候，需要我們做出明智的選擇，怎么明智？
全索引列的選擇性：

root@test 08:10:35>select count(distinct(url))/count(*) from article;
+——————————-+
| count(distinct(url))/count(*) |
+——————————-+
|            0.0750 |
+——————————-+

對(duì)各種長(zhǎng)度的前綴列計(jì)算其選擇性：

root@test 08:16:41>select count(distinct left(url,76))/count(*) url_76,
-> count(distinct left(url,77))/count(*) url_77,
-> count(distinct left(url,78))/count(*) url_78,
-> count(distinct left(url,79))/count(*) url_79,
-> count(distinct left(url,80))/count(*) url_80,
-> count(distinct left(url,81))/count(*) url_81,
-> count(distinct left(url,82))/count(*) url_82,
-> count(distinct left(url,83))/count(*) url_83,
-> count(distinct left(url,84))/count(*) url_84,
-> count(distinct left(url,85))/count(*) url_85
-> from article;
+——–+——–+——–+——–+——–+——–+——–+——–+——–+——–+
| url_76 | url_77 | url_78 | url_79 | url_80 | url_81 | url_82 | url_83 | url_84 | url_85 |
+——–+——–+——–+——–+——–+——–+——–+——–+——–+——–+
| 0.0747 | 0.0748 | 0.0749 | 0.0749 | 0.0749 | 0.0749 | 0.0749 | 0.0749 | 0.0749 | 0.0750 |
+——–+——–+——–+——–+——–+——–+——–+——–+——–+——–+
1 row in set (1.82 sec)

我們看到選擇85的長(zhǎng)度的時(shí)候，該前綴列的選擇性和全列的選擇性相當(dāng)了：
alter table article add index ind_article_url(url(85)),而不必選擇383個(gè)字節(jié)作為前綴；
但是前綴索引還是有一點(diǎn)不足的地方，就是在查詢語(yǔ)句中order by 和group by不能使用到前綴索引

root@test 08:49:24>explain select id,url,deleted from article group by url;
+—-+————-+————-+——+—————+——+———+——+——–+———————————+
| id | select_type | table    | type | possible_keys | key | key_len | ref | rows  | Extra              |
+—-+————-+————-+——+—————+——+———+——+——–+———————————+
| 1 | SIMPLE   | article | ALL | NULL     | NULL | NULL  | NULL | 139844 | Using temporary; Using filesort |
+—-+————-+————-+——+—————+——+———+——+——–+———————————+
1 row in set (0.00 sec);

您可能感興趣的文章: