varchar int 查詢 到底什麼狀況下走索引？

 

一個字符類型的、一個int類型的，查詢的時候到底會不會走索引，其實不少工做了幾年的開發人員有時也會暈，下面就用具體事例來測試一下。

1.  準備工做

先準備2張表，以備後續測試使用。

表1：建立表test1,總共3列，其中id 是主鍵（int）,c_no 爲int型，且有索引，c_2爲普通字段

/*建立表test1 */
create table  test1(id int primary key,c_no  int ,c_2 varchar(1),key c_no(c_no));

/* 插入一些測試數據 */
insert  into test1 values(1,1,'0'),(2,2,'1'),(3,4,'1'),(4,6,'0'),(5,7,''1),(6,11,'2'),(7,5,'3'),(8,100,'0'),(9,30,'1'),(10,50,'0');

表2： 建立表test1,總共3列，其中id 是主鍵（int）,c_no 爲字符型，且有索引，c_2爲普通字段

/* 建立test2 */
create table  test2(id int primary key  auto_increment,c_no  varchar(11) ,c2 varchar(2),key c_no(c_no));

/* 插入一些測試數據 */
 insert  into test2 values(1,'5','1'),(4,'100','0'),(3,'30','1'),(10,'500','0'),(11,'20','0'),(12,'20a','0'),(15,'020b','1');

兩張表的差別是c_no的字段類型不一樣。

 

2.    等值查詢測試

2.1  測試test1

test1.c_no字段爲int類型，下面分別用整型和字符串進行比較，查看是否走索引。對應的執行計劃以下：

mysql> explain  select *  from test1 where c_no='100';
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | test1 | NULL       | ref  | c_no          | c_no | 5       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> explain  select *  from test1 where c_no=100;
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | test1 | NULL       | ref  | c_no          | c_no | 5       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

可見，兩種方式均走索引了，且走的是c_no的索引，類型爲ref爲const（常量的等值查詢），掃行數爲1

也就是說當表中的字段類型爲整型時，不管查詢用字符串類型的數字仍是int類型的數字均能走索引。其中用int類型的值查詢能走索引能夠容易理解，那麼，字符型的爲何能走？ 其實這裏的字符類型作了隱式轉化，上例中就至關於

mysql> explain  select *  from test1 where c_no=CAST('100' as UNSIGNED); +----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | test1 | NULL       | ref  | c_no          | c_no | 5       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

 

2.2  測試 test2 表

以一樣的方式測試一下test2的查詢狀況

先測試正常狀況下字符型與字符型比較，結果可想而知，能夠走索引，以下：

mysql> explain  select *  from test2 where c_no='100';
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | test2 | NULL       | ref  | c_no          | c_no | 47      | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

而，若是是整型再查呢？結果以下（很遺憾，不能走索引了）

mysql> explain  select *  from test2 where c_no=100;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | test2 | NULL       | ALL  | c_no          | NULL | NULL    | NULL |    7 |    14.29 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 3 warnings (0.00 sec)

也就是說，表中字段爲字符類型的時候，查詢的值爲整型時，沒法走索引了。

那這句至關於以下狀況：

mysql> explain  select *  from test2 where cast(c_no  as  unsigned)=100;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | test2 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    7 |   100.00 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

也就是c_no作了隱式轉化。由於若是是100作了影視轉化，那麼結果應該是能夠走索引，例如：

mysql> explain  select *  from test2 where c_no=cast(100 as char);
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | test2 | NULL       | ref  | c_no          | c_no | 47      | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

由此，咱們也應證了若是字段作了函數計算後，該列上即便有索引也沒法使用（MySQL8.0以前的版本）。

2.3  進一步測試

其實針對test2表 還能夠測試一點，進一步證實是c_no字段作了隱式轉化，例如：

mysql> select  * from test2 where c_no=20;
+----+------+------+
| id | c_no | c2   |
+----+------+------+
| 11 | 20   | 0    |
| 12 | 20a  | 0    |
| 15 | 020b | 1    |
+----+------+------+
3 rows in set, 2 warnings (0.00 sec)

另外，看到了2個警告，內容以下：

mysql> show warnings;
+---------+------+------------------------------------------+
| Level   | Code | Message                                  |
+---------+------+------------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: '20a'  |
| Warning | 1292 | Truncated incorrect DOUBLE value: '020b' |
+---------+------+------------------------------------------+
2 rows in set (0.00 sec)

更加證實了轉化爲數字型（預轉爲double）

 

3.  小結

經過上面的簡單測試，便可發現以下結論：

• 當表中的字段類型爲整型時，不管查詢用字符串類型的數字仍是int類型的數字均能走索引；
• 表中字段爲字符類型的時候，查詢的值爲整型時，沒法走索引；
• 若是字段作了函數計算後，該列上即便有索引也沒法使用（MySQL8.0以前的版本）

所以開發同窗在寫SQL的時候要注意SQL的寫法，缺乏一個單引號可能致使很大的性能差別。