通過以往的經驗分析得出，資料庫上雲問題可能有以下幾種情況：

1.資料庫跨平臺遷移（PG->MySQL、Oracle->MySQL），淘寶以前就有大量的Oracle遷到MySQL，也是發生過很多問題。

2.跨版本升級（MySQL：5.1->5.5、5.5->5.6），導致了效能問題。

3.資料庫的執行計劃、優化器、引數配置和硬體配置。

4.雲上較明顯就是網路延遲（跨可用區域訪問、公網延遲、網絡卡飽滿）。

應用場景一：一個引數引發的血案

某個客戶正在將本地系統遷移上雲，在RDS上執行時間明顯要比線下自建資料庫執行時間要慢1倍，導致客戶系統割接延期的風險。

根據經驗的沉澱，我們可以分析確認資料庫從雲上遷移到雲下，MySQL沒有更改，所以不是跨平臺遷移和跨版本升級的原因。

優化器版本

接下來，對比優化器版本，可以看到使用者的資料庫版本也沒有問題，故而排除優化器問題。

SQL執行計劃

再看SQL執行計劃，對比線下和雲上的SQL執行計劃，通過觀察rows可以得出，沒有太大變化，排查到這，似乎已經到了山窮水盡的地步。

引數配置

接下來檢查引數配置，發現使用者手工更改了重要的三個引數。

測試驗證

將三個引數一一對比除錯，經過測試驗證，是tmp_table_size的問題，雲上預設是256K，本地是128M，雲上實際上是一種樸實型的執行環境，引數值如果調的很大，其他使用者的記憶體消耗可能就會變大，將tmp_table_size調到128M後，效能有所提升，從18秒降低到7秒，基本與本地持平。

總結排查思路

如果線下環境的SQL低於雲上SQL。第一，檢查執行計劃；第二，檢查資料庫版本和優化器；第三，對比引數和硬體配置；第四，檢視網路延遲。

應用場景二：上雲版本升級帶來效能下降

某手機客戶端上雲，第一次系統切割失敗，資料庫CPU 100%，需要在第二次割接前排除原因。

問題排除——跨版本升級

資料庫CPU100%是比較容易排查的， 可以查詢資料庫中的SQL為什麼慢，發現使用者本地的MySQL版本是5.5，雲上RDS版本是5.6，使用者的一條SQL在本地5.5執行只需要零點幾秒，而在RDS上需要十多秒，導致所有的執行緒都堆積起來了。

資料庫版本發生了變化，最核心的一點就是優化器發生了變化，看圖中執行計劃中的rows，訪問第一個表需要25萬行，並且對25萬行進行排序，工作量巨大，這就是問題所在。

為了更加確定問題，對比優化器在本地正常的情況下的SQL執行計劃，它的rows是非常小的，所以可以推斷是block_nested_loop優化器的優化，導致SQL執行計劃的轉變，進而導致SQL效能下降。

字串儲存時間導致隱士轉換

這是開發習慣導致的問題，gmt_create用字串存時間， 5.5版本加個索引，它能夠利用索引，SQL是沒有問題的。

5.6版本之後，全表掃描280萬資料，所以這條SQL肯定慢，這就是導致CPU100%的根源。

總結排查思路

分析SQL執行計劃，對比資料庫版本和優化器規則。

最佳實踐經驗：保持資料庫版本一致，功能和效能測試缺一不可。

應用場景三：資料庫上雲後效能下降緊急救援

某APP應用上雲後資料庫CPU100%，系統回滾會出現資料丟失；彈性升級需要時間較長，要在白天業務高峰來臨之際消除障礙。

問題排除

對比發現規格配置較小，使用者本地物理機的配置是雲上RDS的規格兩倍，導致慢SQL出現堆積。具體如下：

1.本地物理機配置：2U機箱，2*Intel E5-2609 v2 4核，記憶體：64G；磁碟ssd，Raid5；

2.RDS配置：邏輯CPU8核，記憶體32G，最大IOPS：12000。

優化SQL

SQL的執行計劃性能較低，走了兩個索引的intersect，需要計算大量的資料rows：30137696。第一種解決辦法是控制優化器的策略；第二種辦法讓表走index_finish Time’(‘finish Time)。

採取第二種辦法將idx_delStatus索引刪除，索引刪除後執行計劃恢復正常，效能急速提升。rows只需要40行。

總結排查思路

當效能變慢了，要對比資料庫資源配置，分析SQL執行計劃。

最佳實踐經驗：保持資料庫資源配置一致，功能和效能測試缺一不可。

應用場景四：去“O”上雲的護航故事

某大型系統從Oracle遷移到RDS MySQL，遷移到RDS後出現CPU100%，需要緊急解決。

改寫子查詢

在淘寶去“O”過程中也遇到過類似的問題，排查過程中發現是MySQL的子查詢詬病，Oracle開發人員會經常使用這樣的SQL做子查詢，這個SQL可能就是查薪水為5000塊人的名字，正常的思維邏輯為先查子查詢的結果集，再反帶到外面的表去關聯，子查詢中的結果集是非常小的，迴圈的次數較少，對效能不會有太大影響。但是在MySQL中就不一樣了，MySQL只有一個巢狀迴圈，MySQL的處理邏輯是遍歷employees表中的每一條記錄，代入到子查詢中去，如果employees表太大，就會導致迴圈的次數太多，使SQL效能受影響。

最佳經驗實踐：子查詢在5.1、5.5版本中都存在較大風險，將子查詢改為關聯，使用MySQL5.6的版本可以避免子查詢的問題。

應用場景五：網路延遲造成的效能下降

某電商系統遷移上雲測試過程中發現效能較低，應用程式碼、資料庫配置完全一樣。

網路延遲放大

通過將SQL日誌一行行看，應用日誌一行行的對照，發現原來架構應用和DB實在一臺伺服器上，應用和DB沒有網路互動，更致命的是，原來的系統架構一個訂單要訪問資料庫200多次，到雲上的效應就擴大了，所以效能自然下降了，只能更改程式碼，優化系統呼叫。

最佳實踐經驗：需要考慮上雲後網路延遲對效能的影響，優化應用與資料庫的訪問；應用和資料庫儘量保持在同一個可用區內訪問。

全部總結來看，系統配置要保持一致，包括版本、引數、規格等；還有考慮網路延遲（頻寬、跨機房等）。