這篇文章主要介紹了mysql sql 優化技巧分享,非常不錯，具有參考借鑒價值，需要的朋友可以參考下
有天發現一個帶inner join的sql 執行速度雖然不是很慢(0.1-0.2),但是沒有達到理想速度。兩個表關聯，且關聯的字段都是主鍵，查詢的字段是唯一索引。
sql如下：
SELECT p_item_token.*, p_item.product_type FROM p_item_token INNER?JOIN?p_item?ON?p_item.itemid?=?p_item_token.itemid WHERE p_item_token.token?='db87a780427d4d02ba2bd49fac8xxx';
其中表? p_item_token? 中? itemid 是主鍵， token 是唯一索引。 p_item 中itemid 是主鍵
按照理想速度，應該在0.03s左右正常。但實際為0.2左右，慢了不少。
直接 EXPLAIN 看計劃
EXPLAIN SELECT ??p_item_token.*, ??p_item.product_type FROM ??p_item_token INNER?JOIN?p_item?ON?p_item.itemid?=?p_item_token.itemid WHERE ??p_item_token.token?=?'db87a780427d4d02ba2bd49fac8xxx';
結果：
注意看上面大紅框。p_item表中就是2w條數據，那這個就是全表掃描了。
不正常啊。
加個show warnings 看看。注意：有些情況下SHOW WARNINGS 會沒有結果。我還不知道原因。建議用本地測試數據庫運行。
EXPLAIN SELECT ??p_item_token.*, ??p_item.product_type FROM ??p_item_token INNER?JOIN?p_item?ON?p_item.itemid?=?p_item_token.itemid WHERE ??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的結果，則能看到優化器處理后的語句。如果與原始語句有出入，仔細對比研究能夠發現實際問題。
以上就是MySql Sql 優化技巧的圖文代碼詳細介紹的內容，更多相關內容請關注PHP中文網（www.php.cn）！
