剛入職一互聯網公司，項目正好處於計划上線的時間，由於公司前不久已經購買了rds服務，領導決定嘗試一番！
當然，新事物、雲事物還是要謹慎的。安排我先把測試環境數據庫遷移上去，這里吐槽一下，往rds遷移一個比較大的
數據庫是比較惡心的。2種方式：
1、數據遷移功能
結論：看似很好用，效率極慢，是通過訪問你的數據庫一點點同步數據的。強烈不推薦
2、使用rds配套的管理平台
結論：文件限制一百兆，幸好支持壓縮文件。導入233M數據耗時121229，也就是121秒，貌似還可以。但是
其他功能確實比較雞肋。
OK，以上就是插個話而已，重點看后面，總算數據導入了進入，設置了一些參數后，內外成功連接到rds，
速度測試一番，找到開發讓找了一個比較多的頁面跑一下，問題就出來了，原來在ecs自建mysql的服務器上
對應語句執行了2.8秒，rds上卻執行了11.28秒，反復測試了很多遍，在RDS后台工具上，遠程連接到控制台執行
時間都是11秒-12秒左右。自建庫一直2.6秒左右，發現肯定有問題，立即發起了個工單，描述了問題，就開始漫漫解決指路。
大概過程就是讓我查看explain執行計划，show profile查看執行步驟和耗時，參數優化，對比，版本，最終發現 一個可疑地方：
那就是show profile中 有2個步驟耗時5秒，合起來占用了11秒，步驟名稱為：CreatING sort index
看圖：
至於什么意思，大家自行百度，看工程師回復：
反正就是說我的語句不行啦，要優化，這一點我承認，語句確實比較雜亂，但是為了追求問題
我決定繼續跟蹤下去，這個地方是怎么引起的。可不可以通過參數優化、廢話不多說了，發現問題
是8月26日，為了追求這個Creating sort index到底為啥會這么高，我就繼續追問了下去，ok
重點來了，又是陪她他們進行各種參數調優，沒有任務進展，直至9月22日，近一個月時間，終於今天
給了答復，看圖：
總體的意思呢，我總結下就是說自建庫是在ecs，超出sort_buffer_size的內容可以在tmp目錄執行，
而且這個tmp目錄是一個很特別的目錄，他掛載在內存上，所有速度快。而RDS呢，不好意思，超出
參數設置的內容是不會去rds物理服務器tmp目錄的執行的，因為rds的產品機制是不允許的，所以超出的部分
就轉到了磁盤執行，就跟自建庫產生了極大的差別，說白了就是少了一條捷徑。
問題總結：
當查詢及排序內容過多的時候，會使用內存運行，內存不夠，就用物理磁盤，兩者差別就在於rds本身不會去想物理機申請內存
而自建庫卻可以。
阿里雲解決方法：
1、修改sort_buffer_size 的session值，讓更多的內容在內存上執行，但是高並發的環境會造成數據庫內容占滿，拒絕服務，
因為這個參數是連接古來申請的時候一次性分配的。所以不宜太高。
2、繼續優化sql語句的涉及到的表的主鍵、索引和sql語法，這個就不啰嗦了。
PS:此問題解決了近一個月，多次電話溝通，問題在后台高級dba分析了好久都沒什么進展，造成了一個問題脫了一個月，也對我們業務
上線產生了影響，最后不得已先用ecs建庫，另外：順便問了阿里雲Postgresql也存在類似問題。請大家參考，當然說到底還是我們的sql有問題。