簡單分析MySQL中的primary key功能

在5.1.46中最佳化器在對primary key的選擇上做了一點改動：

Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be preferred, making full table scans less likely。

該版本中增加了find_shortest_key函式，該函式的作用可以認為是選擇最小key length的

索引來滿足我們的查詢。

該函式是怎麼工作的：

複製程式碼 程式碼如下:What find_shortest_key should do is the following. If the primary key is a covering index

and is clustered, like in MyISAM, then the behavior today should remain the same. If the

primary key is clustered, like in InnoDB, then it should not consider using the primary

key because then the storage engine will have to scan through much more data.

呼叫Primary_key_is_clustered()，當返回值為true，執行find_shortest_key：選擇key length最小的覆蓋索引（Secondary covering indexes），然後來滿足查詢。

首先在5.1.45中測試：

?

建立索引ind_1：

?

新增ind_2：

?

上面的版本【5.1.45】中，可以看到最佳化器選擇使用主鍵來完成掃描，並沒有使用ind_1，ind_2來完成查詢；

接下來是：5.1.48

?

建立索引ind_1：

?

版本【5.1.48】中首先明智的選擇ind_1來完成掃描，並沒有考慮到使用主鍵（全索引掃描）來完成查詢，隨後新增ind_2，由於 ind_1的key長度是大於ind_2 key長度，所以mysql選擇更優的ind_2來完成查詢，可以看到mysql在選擇方式上也在慢慢智慧了。

觀察效能：

?

對比效能：

?

從上面的profile中可以看到在Sending data上，差異還是比較明顯的，mysql不需要掃描整個表的頁塊，而是掃描表中索引key最短的索引頁塊來完成查詢，這樣就減少了很多不必要的資料。

PS:innodb是事務引擎，所以在葉子節點中除了儲存本行記錄外，還會多記錄一些關於事務的資訊（DB_TRX_ID ,DB_ROLL_PTR 等)，因此單行長度額外開銷20個位元組左右，最直觀的方法是將myisam轉為innodb，儲存空間會明顯上升。那麼在主表為t(id,name,pk(id)),二級索引ind_name(name,id),這個時候很容易混淆，即使只有兩個欄位，第一索引還是比第二索引要大（可以透過innodb_table_monitor觀察表的的內部結構）在查詢所有id的時候,最佳化器還是會選擇第二索引ind_name。