通過以往的經驗分析得出，資料庫上雲問題可能有以下幾種情況：
1.
資料庫跨平台遷移（pg->mysql、oracle->mysql），淘寶以前就有大量的oracle遷到mysql，也是發生過很多問題。
2.
跨版本更新（mysql：5.1->5.5、5.5->5.6），導緻了性能問題。
3.
資料庫的執行計劃、優化器、參數配置和硬體配置。
4.
雲上較明顯就是網絡延遲（跨可用區域通路、公網延遲、網卡飽滿）。
應用場景一：一個參數引發的血案
某個客戶正在将本地系統遷移上雲，在rds上運作時間明顯要比線下自建資料庫運作時間要慢1倍，導緻客戶系統割接延期的風險。
根據經驗的沉澱，我們可以分析确認資料庫從雲上遷移到雲下，mysql沒有更改，是以不是跨平台遷移和跨版本更新的原因。
<b>優化器版本</b><b></b>
接下來，對比優化器版本，可以看到使用者的資料庫版本也沒有問題，故而排除優化器問題。
<b>sql</b><b>執行計劃</b><b></b>
再看sql執行計劃，對比線下和雲上的sql執行計劃，通過觀察rows可以得出，沒有太大變化，排查到這，似乎已經到了山窮水盡的地步。
<b>參數配置</b><b></b>
接下來檢查參數配置，發現使用者手工更改了重要的三個參數。
<b>測試驗證</b><b></b>
将三個參數一一對比調試，經過測試驗證，是tmp_table_size的問題，雲上預設是256k，本地是128m，雲上實際上是一種樸實型的運作環境，參數值如果調的很大，其他使用者的記憶體消耗可能就會變大，将tmp_table_size調到128m後，性能有所提升，從18秒降低到7秒，基本與本地持平。
<b>總結排查思路</b><b></b>
如果線下環境的sql低于雲上sql。第一，檢查執行計劃；第二，檢查資料庫版本和優化器；第三，對比參數和硬體配置；第四，檢視網絡延遲。
應用場景二：上雲版本更新帶來性能下降
某手機用戶端上雲，第一次系統切割失敗，資料庫cpu 100%，需要在第二次割接前排除原因。
<b>問題排除——跨版本更新</b><b></b>
資料庫cpu100%是比較容易排查的， 可以查詢資料庫中的sql為什麼慢，發現使用者本地的mysql版本是5.5，雲上rds版本是5.6，使用者的一條sql在本地5.5執行隻需要零點幾秒，而在rds上需要十多秒，導緻所有的線程都堆積起來了。
資料庫版本發生了變化，最核心的一點就是優化器發生了變化，看圖中執行計劃中的rows，通路第一個表需要25萬行，并且對25萬行進行排序，工作量巨大，這就是問題所在。
為了更加确定問題，對比優化器在本地正常的情況下的sql執行計劃，它的rows是非常小的，是以可以推斷是block_nested_loop優化器的優化，導緻sql執行計劃的轉變，進而導緻sql性能下降。
<b>字元串存儲時間導緻隐士轉換</b><b></b>
這是開發習慣導緻的問題，gmt_create用字元串存時間， 5.5版本加個索引，它能夠利用索引，sql是沒有問題的。
5.6版本之後，全表掃描280萬資料，是以這條sql肯定慢，這就是導緻cpu100%的根源。
分析sql執行計劃，對比資料庫版本和優化器規則。
最佳實踐經驗：保持資料庫版本一緻，功能和性能測試缺一不可。
應用場景三：資料庫上雲後性能下降緊急救援
某app應用上雲後資料庫cpu100%，系統復原會出現資料丢失；彈性更新需要時間較長，要在白天業務高峰來臨之際消除障礙。
<b>問題排除</b><b></b>
對比發現規格配置較小，使用者本地實體機的配置是雲上rds的規格兩倍，導緻慢sql出現堆積。具體如下：
本地實體機配置：2u機箱，2*intel e5-2609 v2 4核，記憶體：64g；磁盤ssd，raid5；
rds配置：邏輯cpu8核，記憶體32g，最大iops：12000。
<b>優化</b><b>sql</b>
sql的執行計劃性能較低，走了兩個索引的intersect，需要計算大量的資料rows：30137696。第一種解決辦法是控制優化器的政策；第二種辦法讓表走index_finish time’(‘finish time)。
采取第二種辦法将idx_delstatus索引删除，索引删除後執行計劃恢複正常，性能急速提升。rows隻需要40行。
當性能變慢了，要對比資料庫資源配置，分析sql執行計劃。
最佳實踐經驗：保持資料庫資源配置一緻，功能和性能測試缺一不可。
應用場景四：去“o”上雲的護航故事
某大型系統從oracle遷移到rds mysql，遷移到rds後出現cpu100%，需要緊急解決。
<b>改寫子查詢</b><b></b>
在淘寶去“o”過程中也遇到過類似的問題，排查過程中發現是mysql的子查詢诟病，oracle開發人員會經常使用這樣的sql做子查詢，這個sql可能就是查薪水為5000塊人的名字，正常的思維邏輯為先查子查詢的結果集，再反帶到外面的表去關聯，子查詢中的結果集是非常小的，循環的次數較少，對性能不會有太大影響。但是在mysql中就不一樣了，mysql隻有一個嵌套循環，mysql的處理邏輯是周遊employees表中的每一條記錄，代入到子查詢中去，如果employees表太大，就會導緻循環的次數太多，使sql性能受影響。
最佳經驗實踐：子查詢在5.1、5.5版本中都存在較大風險，将子查詢改為關聯，使用mysql5.6的版本可以避免子查詢的問題。
應用場景五：網絡延遲造成的性能下降
某電商系統遷移上雲測試過程中發現性能較低，應用代碼、資料庫配置完全一樣。
<b>網絡延遲放大</b><b></b>
通過将sql日志一行行看，應用日志一行行的對照，發現原來架構應用和db實在一台伺服器上，應用和db沒有網絡互動，更緻命的是，原來的系統架構一個訂單要通路資料庫200多次，到雲上的效應就擴大了，是以性能自然下降了，隻能更改代碼，優化系統調用。
最佳實踐經驗：需要考慮上雲後網絡延遲對性能的影響，優化應用與資料庫的通路；應用和資料庫盡量保持在同一個可用區内通路。
全部總結來看，系統配置要保持一緻，包括版本、參數、規格等；還有考慮網絡延遲（帶寬、跨機房等）。
本文根據阿裡雲技術專家玄慚于10月14日在2016年杭州雲栖大會上的題為“資料庫上雲經典案例分析”的演講整理而成。