千萬數據量下的真實業務場景SQL性能優化
前 言
通過前幾期文章的積累，現在我們的理論知識已經極為扎實了，這個時候就可以動手開始sql優化了，sql優化是非常重要，因為即使再好的MySQL設計架構，也扛不住一個頻繁查詢的垃圾sql語句。
關于sql的優化，我們也是有一定的原則和先后順序的，大體的步驟的我們用一張流程圖來看一下：
總體呢，大概可以分為以下幾個步驟：
（1）首先，我們得要看下sql語句中是否有join語句，比如內連接查詢inner join，外連接查詢 left join right join等；因為join語句一般都涉及到跨表查詢了，所以首先我們得要為join語句中，負責連接兩張表的字段創建索引，這樣的話可以利用索引加快兩張表關聯的速度。
（2）接下來，我們會再看一下sql語句中的where語句，我們可以根據當前表中的數據量，以及where語句的過濾條件，預估下查詢結果的數據量是否會很大，如果數據量很大的話，查詢的速度肯定就會很慢，所以，為了提高sql語句的執行效率，我們得要為where語句中過濾字段單獨創建索引。
（3）當我們把join語句以及where語句中的字段優化完之后，就可以來看一下其他的一些細節部分，比如sql語句中如果使用了聚合函數，或者對查詢的結果進行了排序，那么，一般我們都建議為聚合函數中的字段，以及排序的字段都創建索引，讓這些操作利用索引速度更快點。
sql優化中不管是對where語句、聚合函數、還是排序操作的優化，優化起來相對而言會簡單點，為對應的字段創建合適的索引就可以了，但是，join語句這塊的優化涉及到一些比較重要的原理，我們還是有必要來看下的。
簡單來說，在mysql中使用join語句關聯2張表的話，比如執行這條sql：
這個時候，join關聯查詢的過程是什么樣子的呢？其實，這個就取決于當前join語句用到的算法了，join語句一共有3種算法，最基礎的是Simple nested loop算法，接下來，我們一起來看下。
Simple nested loop算法
Simple nested loop算法，說白了就是一個雙重for循環遍歷的算法，Simple nested loop算法匹配的過程是這樣的：
從左邊的驅動表order_info中，每取出一條記錄都要遍歷一遍被驅動表order_item_detail，說白了就是一個雙重for循環。
如果驅動表和被驅動表中都有100條數據的話，那么此時就需要匹配 100 * 100 = 10000次，可見效率是非常低的，所以，MySQL并沒有選擇使用 Simple nested loop 算法，而是使用了優化后的Block nested loop 算法。
Block nested loop 算法
Block nested loop 算法對 Simple nested loop 算法進行了優化，它引入了 join buffer，join buffer 主要用于優化不帶索引條件的 join 查詢，它會緩存連接過程中用到的字段，這樣可以有效減少匹配次數，就像這樣：
可以看到，Block nested loop的優化思路，是減少被驅動表的匹配次數，它主要是通過一次性緩存驅動表的多條數據，以此來減少被驅動表的匹配次數，從而可以達到提升性能的目的。
需要注意的是，MySQL提供了一個參數join buffer_size，它是用來控制 join buffer 大小的，而MySQL默認的join_buffer_size 是 256K，所以如果驅動表的數據太多的話，默認的join buffer可能一次性放不下全部的數據。
這個時候，join buffer就會采用分段緩存的機制來緩存驅動表的數據，但是這種分段緩存方式的性能，是比一次性緩存全部數據要差一些的。
所以，我們可以通過join_buffer_size參數，適當調大join buffer的大小，使join buffer可以一次性放下驅動表的所有數據，這樣可以提升join的性能。
Index nested loop算法
最后還有一種Index nested loop算法：
它的優化思路主要是減少被驅動表數據的匹配次數， 就是驅動表直接與被驅動表的索引進行匹配，這樣就不用和被驅動表的每條記錄比較了。
原來的匹配次數為：驅動表行數 * 被驅動表行數，而現在變成了：驅動表行數 * 被驅動表索引的高度，這樣就極大的減少了被驅動表的匹配次數，極大的提升了join的性能。
如果join關聯查詢能使用到索引的話，MySQL就會使用Indexnestedloop算法，如果無法使用Indexnestedloop算法，MYSQL默認會使用Blocknestedloop算法。
到底能不能使用join？
好了，我們剛才了解了Simple nested loop 、 Block nested loop、Index nested loop 這三種算法，那么現在可以回答開頭的問題了：到底能不能使用join？
其實，如果能用上被驅動表上的索引，說白了就是可以用上 Index nested loop 算法的話，是可以使用 join 的。
而如果使用的是 Block nested loop 算法的話，由于掃描行數和比較次數會比較多，所以會占用大量的系統資源，所以這種情況能不用join就不用join。
我們平常使用explain優化sql的時候，如果 explain 結果中的 Extra 字段，如果包含 ' Using join buffer (Block Nested Loop) ' 的話，這個時候就代表使用了 Block nested loop 算法了。
如果能使用上被驅動表上的索引的話，join還是可以使用的，這個時候基本不會影響性能，那么我們這里為什么要優化掉join呢？
主要由于2個原因，首先后邊我們有分庫分表的計劃，所以為了有更好的擴展性，我們會優化掉join，其次MySQL是專門用來做數據存儲的，所以，還是盡量不要把業務相關的邏輯放到MySQL層面來做。
所以基于這2個原因，我們會將單體應用版本的join給優化掉。
join關聯查詢優化實戰
被驅動表order_no列未加索引
（1）join關聯查詢sql語句
可以看到，sql語句中，left join語句中，訂單明細表是通過order_no字段和訂單表關聯的，此時驅動表order_info的order_no是加了索引的，而被驅動表order_item_detail的order_no字段沒有添加索引
（2）看一下查詢時間
此時order_info中的數據量為2500萬條，而訂單明細表 order_item_detail 的數據量是1億條。
可以看到被驅動表order_item_detail沒使用到索引時，查詢效率是非常低下的。
優化：被驅動表order_no列添加索引
（1）為被驅動表添加索引
現在我們為被驅動表order_item_detail的order_no添加索引，添加索引sql如下：
（2）再次查看join關聯查詢的時間
此時我們發現被驅動表order_item_detail的關聯字段order_no用上索引后，查詢效率提升的非常明顯。
進一步優化：去掉join
此時我們為了更好的擴展性，需要將join關聯查詢給優化掉
（1）看下join優化后的代碼：
拆分join,改成單表查詢，內存中再組裝數據。
（2）看一下優化后的時間
可以看到，將join關聯查詢優化掉之后，我們除了可以獲取到更大的擴展性外，可以發現對查詢性能的提升也是非常大的。
被動向主動的轉變，監控系統誕生
在sql優化這個例子中，這個問題是由DBA同學發現的，然后DBA同學將問題反饋給了我們，實際在工作中呢，也可能是產品同學發現訂單信息查詢頁面有點慢，然后將問題反饋給我們。
不管是誰發現的，對于我們訂單系統的開發人員來說都是非常被動的，因為我們不能及時主動的發現問題，比如某一個接口變慢了，我們不能及時知道，只能等別人反饋給我們，這樣被動的發現問題，會在一定程度上擴大問題的影響。
為了解決這個問題，我們建立了一套完善的監控系統，這個監控系統呢，可以添加很多監控面板，比如我們可以添加訂單的監控面板，訂單監控面板中的核心指標包含：訂單核心接口的請求次數、失敗次數、TP50、TP99等等。
然后，為了及時發現問題，這個監控系統還集成了報警的功能，說白了就是針對某一個監控指標，我們會設置一個報警規則，比如每天的某一個時間段，在多少分鐘內，失敗請求超過多少，那么就會報警給對應的開發人員，報警方式呢，會分為2種，分別是報警電話和消息推送（推送給公司內部的辦公聊天軟件）
報警的時候為了避免開發人員的單點故障，報警接收人一般會添加多個，如果第一個人不接報警電話的話，那么就順延給第二個人打電話，這樣就可以最大程度的及時發現問題了，就可以真正的由被動轉為主動了。
