【庫房】——SQL語句優化
前言
前段時間接手庫房專案之後，有很多地方需要優化，從中也學到了很多東西，將在部落格中一一整理出來分享給大家。
實際案例：庫房系統中管理員許可權下的入庫管理中的入庫記錄頁面每次開啟時都載入的非常慢，長達三十多秒，網速慢的時候會達到一分鐘左右，這個問題非常影響庫房系統的功能使用，首先需要解決的就是這個問題。最後我們找到了問題所在，原來是D層下的SQL語句的問題，查詢速率快慢和SQL語句的查詢順序密切相關，想必大家在軟考中也做過類似的題，除此之外還可以通過建索引來提高查詢速度，還有一種方法就是寫一個介面。
正文
1、資料庫優化的目的
避免出現頁面訪問錯誤：
- 由於資料庫連線timeout產生頁面5xx錯誤
- 由於慢查詢造成頁面無法載入
- 由於阻塞造成資料無法提交
增加資料庫的穩定性：
- 很多資料庫問題都是由於低效的查詢引起的
優化使用者體驗：
- 流暢頁面的訪問速度
- 良好的網站功能體驗
可以從幾個方面進行資料庫優化：
2、SQL及索引優化
慢查日誌的分析工具：
- 輸出到檔案：pt-query-digest slow-log > slow_log.report
- 輸出到資料庫表：
pt-query-digest slow.log -review\
h=127.0.0.1,D=test,p=root,P=3306,u=root,t=query_review\
--create-reviewtable\
--review-history t=hostname_slow
慢查日誌的分析工具——pt-query-digest輸出：
3、如何通過慢查日誌發現有問題的SQL？
1、查詢次數多且每次查詢佔用時間長的SQL
通常為pt-query-digest分析的前幾個查詢
2、IO大的SQL
注意pt-query-digest分析中的rows examine項
3、未命中索引的SQL
注意pt-query-digest 分析中rows examine和rows send的對比
4、使用explain查詢SQL的執行計劃
案例：在Navicat Premium中展示一個explain的具體使用效果：
如何 分析SQL查詢，下面解釋explain返回各列的含義：
table：顯示這一行的資料是關於哪張表的
type：這一列很重要，顯示連線使用了何種型別。從最好到最差的連線型別為const，eq_reg,ref,range,index ,ALL
possible_keys：顯示可能應用在這張表中的索引。如果為空，沒有可能的索引。
key：實際使用的索引。如果為NULL，則沒有使用索引。
key_len:使用的索引的長度。在不損失精確性的情況下，長度越短越好。
ref：顯示索引的哪一列被使用了，如果可能的話，是一個常數。
rows:MySQL認為必須檢查的用來返回請求資料的行數。
extra列需要注意的返回值：
1、Using filesort：看到這個的時候，查詢就需要優化了。MySQL需要進行額外的步驟來發現如何對返回的行排序。它會根據連線型別以及儲存排序鍵值和匹配條件的全部行的行指標來排序全部行。
2、Using temporary：看到這個的時候，查詢需要優化。MySQL需要建立一個臨時表來儲存結果，通常發生在不同的列集進行ORDER BY上，而不是GROUP BY上。