高效能MySQL之查詢優化

查詢執行引擎

結果返回給客戶端

mysql查詢的一些優化建議

reference

查詢優化、索引優化、庫表結構優化需要齊頭並進，乙個不落。

-- 檢視慢查詢時間

show variables like
"long_query_time";預設10s
-- 檢視慢查詢配置情況
show status like
"%slow_queries%";
-- 檢視慢查詢日誌路徑
show variables like
"%slow%";
-- 檢視表被鎖狀態
show
open tables where in_use > 0;

對於第一類慢查詢，也就是由於返回了過多的列或行導致的慢查詢，往往是因為我們程式設計時沒有意識到或者考慮不周導致。這裡面還有一種情況，就是我們出於簡化開發的考慮，經常會返回所有列，這種做法是值得考慮的，但需要知道這背後的代價是什麼，如果有用不到的text或blob的列，最好就不要每次查詢都返回了。

對於第二類慢查詢，就需要借助執行計畫來進行分析了

了解mysql的執行過程是優化查詢的基礎，不要盲目相信一些所謂的「軍規」或者「訣竅」，這些經驗都有一定的適用範圍，只有了解了執行過程，我們才能夠知道它們的侷限性，並有能力做出根據具體應用情況，做出一些「反常識」的優化。

mysql使用半雙工通訊協議，這意味著同一時間要麼是客戶端向伺服器傳送資料，要麼是伺服器向客戶端傳送資料，兩者無法同時進行。這種簡單快速的協議也意味著一旦一端開始傳送資料，另一端要接受完整個訊息才能響應它。

- show full processlist可以檢視正在執行的sql處於那種狀態

- max_allowed_packet可以設定伺服器接受的最長的查詢語句大小

shell> mysql --max_allowed_packet=16777216

shell> mysql --max_allowed_packet=16m

mysql通過查詢優化器把上一步解析得到的「語法樹」轉化為執行計畫，一條查詢通常有若干種執行方式，優化器會從中選擇一條它認為成本最低的。mysql成本的最小單位是基於隨機讀取乙個4k資料頁的成本，再加上一些估算某些操作代價的「因子」，通過show status like 『last_query_cost』可以檢視上一條查詢的成本。

優化器的優化規則是相當複雜的，我們最好不要「自以為比優化器更聰明」。

不要盲目相信任何優化建議，這些建議可能僅僅在某些場景或某些mysql版本中是正確的，所以一定要檢視執行計畫。

mysql**指令碼

《高效能MySQL》之MySQL查詢效能優化

響應時間過長。如果把查詢看做是乙個任務，那麼它由一系列子任務組成，每個子任務都會消耗一定的時間。如果要優化查詢，實際上優化其子任務，要麼消除其中一些子任務，要麼減少子任務的執行次數，要麼讓子任務執行得更快。查詢的生命週期 客戶端 伺服器 伺服器上解析 生成執行計畫 執行 返回結果給客戶端。其中 執行...

高效能MySQL之查詢效能優化（四）

本文內容基於 高效能mysql 第三版，寧海元 周振興 彭立勛 翟衛祥等譯。高效能 庫表結構優化 索引優化 查詢優化。如果要優化查詢，實際上要優化其子任務，要麼消除其中一部分子任務，要麼減少子任務的執行次數，要麼讓子任務執行得更快。通常來說，查詢的生命週期大致可以按照順序來看 從客戶端，到伺服器，然...

《高效能MySQL》第6章 查詢效能優化

6.2 慢查詢基礎 優化資料訪問 6.2.1 是否向資料庫請求了不需要的資料 有些查詢會請求超過實際需要的資料，然後這些多餘的資料會被應用程式丟棄。這會給mysql伺服器帶來額外的負擔，並增加網路開銷，另外也會消耗應用伺服器的cpu和記憶體資源。6.2.2 mysql是否在掃瞄額外的記錄6.3 重構...