有天發現一個帶inner join的sql 執行速度雖然不是很慢(0.1-0.2),但是沒有達到理想速度。兩個表關聯，且關聯的字段都是主鍵，查詢的字段是唯一索引。
sql如下：
SELECTp_item_token.*,p_item.product_typeFROMp_item_tokenINNER JOIN p_item ON p_item.itemid = p_item_token.itemidWHEREp_item_token.token ='db87a780427d4d02ba2bd49fac8xxx';
其中表 p_item_token 中 itemid 是主鍵， token 是唯一索引。 p_item 中itemid 是主鍵
按照理想速度，應該在0.03s左右正常。但實際為0.2左右，慢了不少。
直接 EXPLAIN 看計劃
EXPLAINSELECT p_item_token.*, p_item.product_typeFROM p_item_tokenINNER JOIN p_item ON p_item.itemid = p_item_token.itemidWHERE p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';
結果：
注意看上面大紅框。p_item表中就是2w條數據，那這個就是全表掃描了。
不正常啊。
加個show warnings 看看。注意：有些情況下SHOW WARNINGS 會沒有結果。我還不知道原因。建議用本地測試數據庫運行。
EXPLAINSELECT p_item_token.*, p_item.product_typeFROM p_item_tokenINNER JOIN p_item ON p_item.itemid = p_item_token.itemidWHERE p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';SHOW WARNINGS;
結果2里面顯示code=1003.后面有個sql語句。這個語句就是mysql把我們輸入的sql語句，按照規則改寫之后執行的最終語句。
/* select#1 */SELECT '0000eb612d78407a91a9b3854ffffffff' AS `itemid`, /*注:直接按主鍵把值查出來了*/ 'db87a780427d4d02ba2bd49fac8cf98b' AS `token`, '2016-12-16 10:46:53' AS `create_time`, '' AS `ftoken`, `p_db`.`p_item`.`product_type` AS `product_type` FROM `p_db`.`p_item_token`JOIN `p_db`.`p_item`WHERE ( ( CONVERT ( `p_db`.`p_item`.`itemid` USING utf8mb4 ) = '0000eb612d78407a91a9b3854fffffff' ) )
奇怪啊。Where中怎么有個 CONVERT ？我們知道，如果where條件中，等式的左邊，也就是要查詢的字段上有函數的話，就會導致慢。（我的理解：慢因為索引用不到了。索引的值是原始值，這個條件中用的卻是處理后的值。）
注意看這函數，意思是把 itemid 這一列的編碼轉換成 utf8mb4 .也就是說，這一列的編碼不是 utf8mb4 !
打開表，把兩個表中itemid這一列的編碼都改成utf8。再次運行解釋。
從解釋結果來看已經沒有問題了。
再看下結果2中的語句：
/* select#1 */SELECT '0000eb612d78407a91a9b3854fffffff' AS `itemid`, 'db87a780427d4d02ba2bd49fac8cf98b' AS `token`, '2016-12-16 10:46:53' AS `create_time`, '' AS `ftoken`, 'cxx' AS `product_type`FROM `toy_item_plat`.`p_item_token`JOIN `toy_item_plat`.`p_item`WHERE 1
這 select 中全是常量了。速度能不快嗎？
執行結果0.036s。符合預期
經驗總結:
explain 可以查看執行計劃是否符合預期，如果有出現rows較大的情況，則說明出現了全表掃描，將來會是性能瓶頸
show warning的結果，則能看到優化器處理后的語句。如果與原始語句有出入，仔細對比研究能夠發現實際問題。
新聞熱點
疑難解答
