《MySQL死鎖分析的兩個(gè)工具》中，舉了一個(gè)強(qiáng)制類型轉(zhuǎn)換導(dǎo)致死鎖的例子，有朋友詢問是不是類型轉(zhuǎn)換都不能命中索引，花1分鐘細(xì)說一下。

第一類：“列類型”與“where值類型”不符，不能命中索引，會(huì)導(dǎo)致全表掃描(full table scan)。

數(shù)據(jù)準(zhǔn)備：

create table t1 ( cell?varchar(3) primary key )engine=innodb default charset=utf8;insert into t1(cell) values ('111'),('222'),('333');

（1）cell屬性為varchar類型；

（2）cell為主鍵，即聚簇索引(clustered index)；

（3）t1插入3條測(cè)試數(shù)據(jù)；

測(cè)試語(yǔ)句：

explain select * from t1 where cell=111; explain select * from t1 where cell='111';

（1）第一個(gè)語(yǔ)句，where后的值類型是整數(shù)（與表cell類型不符）；

（2）第二個(gè)語(yǔ)句，where后的值類型是字符串（與表cell類型一致）；

測(cè)試結(jié)果：

（1）強(qiáng)制類型轉(zhuǎn)換，不能命中索引，需要全表掃描，即3條記錄；

（2）類型相同，命中索引，1條記錄；

第二類：相join的兩個(gè)表的字符編碼不同，不能命中索引，會(huì)導(dǎo)致笛卡爾積的循環(huán)計(jì)算（nested loop）。

數(shù)據(jù)準(zhǔn)備：

create table t2 ( cell varchar(3) primary key )engine=innodb default charset=latin1;insert into t2(cell) values ('111'),('222'),('333'),('444'),('555'),('666');create table t3 ( cell varchar(3) primary key )engine=innodb default charset=utf8;insert into t3(cell) values ('111'),('222'),('333'),('444'),('555'),('666');

（1）t2和t1字符集不同，插入6條測(cè)試數(shù)據(jù)；

（2）t3和t1字符集相同，也插入6條測(cè)試數(shù)據(jù)；

（3）除此之外，t1，t2，t3表結(jié)構(gòu)完全相同；

測(cè)試語(yǔ)句：

explain select * from t1,t2 where t1.cell=t2.cell; explain select * from t1,t3 where t1.cell=t3.cell;

（1）第一個(gè)join，連表t1和t2（字符集不同），關(guān)聯(lián)屬性是cell；

（2）第一個(gè)join，連表t1和t3（字符集相同），關(guān)聯(lián)屬性是cell；

測(cè)試結(jié)果：

（1）t1和t2字符集不同，存儲(chǔ)空間不同；

（2）t1和t2相join時(shí)，遍歷了t1的所有記錄3條，t1的每一條記錄又要遍歷t2的所有記錄6條，實(shí)際進(jìn)行了笛卡爾積循環(huán)計(jì)算(nested loop)，索引無效；

（3）t1和t3相join時(shí)，遍歷了t1的所有記錄3條，t1的每一條記錄使用t3索引，即掃描1行記錄；

畫外音：圖片請(qǐng)放大。

總結(jié)

兩類隱蔽的不能利用索引的case：

（1）表列類型，與where值類型，不一致；

（2）join表的字符編碼不同；

畫外音：本文測(cè)試于MySQL5.6。

總結(jié)

以上是生活随笔為你收集整理的两类非常隐蔽的全表扫描，不能命中索引（一分钟系列）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。