提升網站訪問速度的SQL查詢優化技巧
你一定知道，一個快速訪問的網站能讓用戶喜歡，可以幫助網站從Google 上提高排名，可以幫助網站增加轉化率。如果你看過網站性能優化方面的文章，例如 設置服務器的***實現 、到 干掉慢速代碼 以及 使用CDN 加載圖片 ，就認為你的 WordPress 網站已經足夠快了。但是事實果真如此嗎?
使用動態數據庫驅動的網站，例如WordPress，你的網站可能依然有一個問題亟待解決：數據庫查詢拖慢了網站訪問速度。
在這篇文章中，我將介紹如何識別導致性能出現問題的查詢，如何找出它們的問題所在，以及快速修復這些問題和其他加快查詢速度的方法。我會把門戶網站 deliciousbrains.com 出現的 拖慢查詢速度的情況作為實際的案例。
定位
處理慢SQL查詢的***步是找到慢查詢。Ashley已經在之前的 博客 里面贊揚了調試插件 Query Monitor ，而且這個插件的數據庫查詢特性使其成為定位慢SQL查詢的寶貴工具。該插件會報告所有頁面請求過程中的數據庫請求，并且可以通過調用這些查詢代碼或者原件(插件，主題，WordPress核)過濾這些查詢，高亮重復查詢和慢查詢。
要是不愿意在生產安環境裝調試插件(性能開銷原因)，也可以打開 MySQL Slow Query Log ，這樣在特定時間執行的所有查詢都會被記錄下來。這種方法配置和設置存放查詢位置相對簡單。由于這是一個服務級別的調整，性能影響會小于使用調試插件，但當不用的時候也應該關閉。
理解
一旦你找到了一個你要花很大代價找到的查詢，那么接下來就是嘗試去理解它并找到是什么讓查詢變慢。最近，在我們開發我們網站的時候，我們找到了一個要執行8秒的查詢。
我們使用WooCommerce和定制版的WooCommerce軟件插件來運行我們的插件商店。此查詢的目的是獲取那些我們知道客戶號的客戶的所有訂閱。 WooCommerce是一個稍微復雜的數據模型， 即使訂單以自定義的類型存儲，用戶的ID(商店為每一個用戶創建的WordPress)也沒有存儲在 post_author， 而是作為后期數據的一部分。訂閱軟件插件給自義定表創建了一對鏈接。讓我們深入了解查詢的更多信息。
MySQL是你的朋友
MySQL有一個很方便的語句 DESCRIBE ，它可以輸出表結構的信息，比如字段名，數據類型等等。所以，當你執行 DESCRIBE wp_postmeta; 你將會看到如下的結果：
你可能已經知道了這個語句。但是你知道 DESCRIBE語句可以放在SELECT, INSERT, UPDATE, REPLACE 和 DELETE語句前邊使用嗎 ?更為人們所熟知的是他的同義詞 EXPLAIN ，并將提供有關該語句如何執行的詳細信息。
這是我們查詢到的結果：
乍一看，這很難解釋。幸運的是，人們通過SitePoint總結了一個 理解語句的全面指南 。
最重要的字段是 type ，它描述了一張表是怎么構成的。如果你想看全部的內容，那就意味著MySQL要從內存讀取整張表，增加I/O的速度并在CPU上加載。這種被稱為“全表瀏覽”—稍后將對此進行詳細介紹。
rows 字段也是一個好的標識，標識著MySQL將要不得不做的事情，它顯示了結果中查找了多少行。
Explain 也給了我們很多可以優化的信息。例如，pm2表( (wp_postmeta )，告訴我們是 Using filesort， 因為我們使用了 ORDER BY語句對結果進行了排序。如果我們要對查詢結果進行分組，這將會給執行增加開銷。
可視化研究
對于這種類型的研究， MySQL Workbench 是另外一個方便，免費的工具。將數據庫用MySQL5.6及其以上的版本打開， EXPLAIN 的結果可以用JSON格式輸出，同時 MySQL Workbench將JSON轉換成可視化執行語句：
它自動將查詢的問題用顏色著重表示提醒用戶去注意。我們可以馬上看到，連接 wp_woocommerce_software_licences(別名l) 的表有嚴重的問題 。
解決
你 應該避免 這種全部表瀏覽的查詢，因為他使用非索引字段 order_id 去連接 wp_woocommerce_software_licences 表和 wp_posts 表 。這對于查詢慢是常見的問題，而且也是比較容易解決的問題。
索引
order_id在表中是一個相當重要的標志性數據，如果想像這種方式查詢，我們需要在列上建立一個 索引 ，除此之外，MySQL將逐字掃描表的每一行，直到找到我們想要的行為止。讓我們添加一個索引并看看它是怎么樣工作的：
- CREATE INDEX order_id ON wp_woocommerce_software_licences(order_id)
哇，干的漂亮!我們成功的添加了索引并將查詢的時間縮短了5s.
了解你的查詢語句
檢查下查詢語句——看看每一個join，每一個子查詢。它們做了它們不該做的事了嗎?這里能做什么優化嗎?
這個例子中，我們把licenses 表和posts 表通過order_id 連接起來同時限制post type 為shop_order。這是為了通過保持數據的完整性來保證我們只使用正確的訂單記錄，但是事實上這在查詢中是多余的。我們知道這是一個關于安全的賭注，在posts 表中software license 行是通過order_id 來跟 WooCommerce order 相關聯的，這在PHP 插件代碼中是強制的。讓我們移除join 來看看有什么提升沒有：
提升并不算很大但 現在 查詢時間低于3 秒了。
緩存一切數據
如果你的服務器默認情況下沒有使用MySQL查詢緩存，那么你應該開啟緩存。開啟緩存意味著MySQL 會把所有的語句和語句執行的結果保存下來，如果隨后有一條與緩存中完全相同的語句需要執行，那么MySQL 就會返回緩存的結果。緩存不會過時，因為MySQL 會在表數據更新后刷新緩存。
查詢監視器發現在加載一個頁面時我們的查詢語句執行了四次，盡管有MySQL查詢緩存很好，但是在一個請求中重復讀取數據庫的數據是應該完全避免的。你的PHP 代碼中的靜態緩存很簡單并且可以很高效的解決這個問題。基本上，***請求時從數據庫中獲取查詢結果，并將其存儲在類的靜態屬性中，然后后續的查詢語句調用將從靜態屬性中返回結果：
- class WC_Software_Subscription {
- protected static $subscriptions = array();
- public static function get_user_subscriptions( $user_id ) {
- if ( isset( static::$subscriptions[ $user_id ] ) ) {
- return static::$subscriptions[ $user_id ];
- }
- global $wpdb;
- $sql = '...';
- $results = $wpdb->get_results( $sql, ARRAY_A );
- static::$subscriptions[ $user_id ] = $results;
- return $results;
- }
- }
緩存有一個生命周期，具體地說是實例化對象有一個生命周期。如果你正在查看跨請求的查詢結果，那么你需要實現一個持久對象緩存。然而不管怎樣，你的代碼應該 負責 設置緩存，并且當基礎數據變更時讓緩存失效。
跳出箱子外思考
不僅僅是調整查詢或添加索引， 還有其他方法可以加快查詢的執行速度。 我們查詢的最慢的部分是從客戶ID到產品ID再到 加入表格 所做的工作，我們必須為每個客戶做到。我們是不是可以在需要的時候抓取客戶的數據?如果是那樣，那 我們就只需要加入一次。
您可以通過創建數據表來存儲許可數據，以及所有許可用戶標識和產品標識符來對數據進行非規范化(反規范化)處理，并針對特定客戶進行查詢。 您需要使用INSERT / UPDATE / DELETE上的 MySQL觸發器 來重建表格(不過這要取決于數據來更改的表格)，這會顯著提高查詢數據的性能。
類似地，如果一些連接在MySQL中減慢了查詢速度，那么將查詢分解為兩個或更多語句并在PHP中單獨執行它們可能會更快，然后可以在代碼中收集和過濾結果。 Laravel 通過 預加載 在 Eloquent 中就做了類似的事情。
如果您有大量數據和許多不同的自定義帖子類型，WordPress可能會在wp_posts表上減慢查詢速度。 如果您發現查詢的帖子類型較慢，那么可以考慮從自定義帖子類型的存儲模型移動到 自定義表格 中 - 更多內容將在后面的文章中介紹。
