如何選購RDS MySQL
目前使用MySQL，首推使用雲盤版（ESSD雲盤），雖然在磁盤讀寫RT上較本地盤差了一些，進而導緻跑分軟體跑出的資料不太好看，但是雲盤有着諸多天然優勢：
使用雲盤還是本地盤？
備份 && 恢複
雲盤（SSD雲盤、ESSD雲盤）：
由于雲盤天然支援使用快照進行資料備份，可以做到幾百G乃至上T的資料都可以在幾分鐘内完成備份，同樣基于備份進行資料還原（克隆執行個體），也可以超快的完成。
再來看看本地盤：
本地盤由于無法采用快照備份，為了保證備份的可靠性，備份也不能存儲到本地，目前是将備份不落地直接備份傳輸到OSS存儲，通常備份到OSS一個3T的執行個體就需要1天以上來備份了，同樣如果需要恢複，雖然比起備份會快些，差不多也要大半天了，假如資料出現問題，一般是非常着急的場景，#如果采用雲盤，可以大大節省寶貴的救火時間#。
還有另外一個問題，由于使用xtrabackup備份，會需要将所有的庫表檔案打開，受限于作業系統，能同時打開的檔案句柄是有限的，假如我們庫裡有60萬以上的表，那麼很有可能無法完成備份。假如長時間不備份，資料的風險不言而喻！
性能
本地盤相較于雲盤來說，由于IO操作不經過網絡，是以RT上來說一定是本地盤更好。但是IOPS可不一定哦~
ESSD雲盤是SSD雲盤的更新版，相較于SSD雲盤來說，ESSD的存儲系統内部采用了更高效的通信機制，進而使得ESSD雲盤有了質的飛躍！ESSD PL1級别性能和SSD雲盤相差不大，但是當達到PL2甚至PL3級别時，性能可以說是突飛猛進。其中PL3級别IOPS最高可達1000000；我們本地盤的版本獨占實體機最高IOPS也隻能達到144000，相較于PL2級别的雲盤稍高一些。
單機版
首先，重要的事情說三遍！不建議使用單機版作為生産環境！不建議使用單機版作為生産環境！不建議使用單機版作為生産環境！
為什麼呢？從成本考慮單機版确實可以節省一大筆開銷，但是受限于單機版的架構，在發生故障時，單機版是無法快速恢複的！是以同樣的單機版的SLA保障很低！
單機版一般來說，隻建議作為開發調試，或者是測試環境使用！
高可用版
作為生産環境标配版本，兼顧成本和可用性，在大部分場景下推薦使用此版本！目前主可用區功能已經上線，執行個體預設建立在同城雙機房，實作跨機房容災能力！
三節點企業版
推薦金融領域的産品使用該産品，由于對核心進行了深度改造，采用了大名鼎鼎Paxos一緻性協定保證了RPO（Recovery Point Object）=0，即在任何使用場景都不會丢失資料，可靠性非常高！
同城三機房部署，具備跨可用區容災能力。還可以搭配異地災備執行個體滿足兩地三中心的容災要求。
想了解更多三節點企業版的優勢，可以到阿裡雲官網檢視相關介紹哦~
使用RDS的注意事項
執行個體卡慢，重新開機執行個體能立馬解決？
大部分情況下，重新開機執行個體都不能解決執行個體卡慢的問題！大部分情況下，重新開機執行個體都不能解決執行個體卡慢的問題！大部分情況下，重新開機執行個體都不能解決執行個體卡慢的問題！
重要的事情還是要說三遍！
重新開機之前請先自查資料庫運作情況，如果是存在DDL操作（可通過show processlist;檢視是否有DDL語句在執行）或者大事務（可通過檢視INFORMATION_SCHEMA.INNODB_TRX表來确認）的情況，重新開機執行個體反而會造成長時間的不可用！因為資料庫在打開端口允許連入之前，需要保證自身資料一緻性，是以需要做recovery或者undo的操作，根據事務的已經執行的時長或是事務本身要執行的時長，強制重新開機可能導緻執行個體數小時無法正常使用！
員工删庫，資料丢失？不存在的！雲上RDS豐富的功能，護航您的寶貴資料！
近期網際網路圈内，“微盟”事件可謂是鬧得沸沸揚揚，删庫後6天都沒能完全恢複資料，究其原因還是他們自建了資料庫，因為是自建的，運維管理人員掌握了極高的權限，甚至可以root權限登機器進行極其危險的操作，哪怕不是有意為之，一條錯誤的指令就可能造成極其嚴重的損失。
然而上雲後，可以實作對資料庫執行個體，乃至庫表級别的細粒度權限控制，運維人員得不到不該有的權限也就無法進行如此高危操作。就算是執行了庫級高危操作drop database，雲上也是有很多解法的，完全不需要花6天之久進行恢複：
解法1：
使用雲上冷備+binlog按時間點克隆，如果發生此類異常，雲盤執行個體一般隻需要幾分鐘的基于快照建立磁盤+數小時binlog重放即可完全恢複，本地盤執行個體也可以根據執行個體備份大小，一般也完全可以在1天内完全恢複。
解法2：
設定延遲讀庫，在發生删庫事件後，立即停止複制，找到發生删庫的時間點讓binlog應用到删庫之前就可以提供隻讀服務了，之後通過解法1所述的克隆執行個體恢複，一般也可以在1天内完全恢複讀寫。
解法3：
目前RDS本地盤已經支援分庫分表恢複，通過這個功能可以表級粒度原地恢複，由于減少了恢複時資料處理量，可以相較于克隆執行個體更快速的完成恢複動作！
不使用MyISAM引擎
為什麼不推薦使用MyISAM引擎？因為MyISAM引擎本身不支援事務，這是一個很大的問題，在高可用版本中，不支援事務會經常因為各種原因（比如OOM自動重新開機，比如主備切換等），導緻備庫和主庫的不一緻，這是從原理上就決定的。而且，由于不支援事務，我們在進行備份時，隻能選擇将整個資料庫執行個體加鎖，進而阻塞寫入，來保證備份的一緻性，假如我們有幾G的非事務資料，那麼備庫損壞時需要修複時（通過主庫備份來重建備庫），可能就有數十分鐘不可寫入了，對執行個體的可用性有不小的沖擊。此外，除了不支援事務意外，MyISAM引擎本身有很多缺陷，這些缺陷同樣會導緻資料損壞甚至丢失，引發主從資料不一緻，現代資料庫看來，相較于InnoDB，MyISAM也沒有什麼明顯優勢，是以還在使用MyISAM引擎的需要盡快評估自己的業務盡快遷移到InnoDB。
請給所有表加主鍵（或隐式主鍵）
為了盡量保證主備資料一緻，我們系統預設采用Row格式的Binlog進行主從同步。
這種格式的Binlog在有主鍵時會使用主鍵作為Where子句的判斷條件寫入binlog如果沒有主鍵時，我們Update 多條資料，會産生使用普通字段作為Where判斷條件的Binlog，這種Binlog在從庫應用時，相較于主鍵一般都需要進行全表掃描，再加上主庫執行一條DML，從庫要執行N條，進而導緻從庫應用效率遠不如主庫，進而迅速産生嚴重的主備延遲。如果存在主鍵，那麼通過主鍵的聚簇索引可以快速定位到要修改的記錄了，進而主庫和從庫可以保持基本追平的狀态。
- 備庫延遲是個很嚴重的問題，在主庫發生當機時，為了保證資料一緻性，系統會判斷備庫延遲在一定範圍内才允許HA切換，如果備庫長期保持延遲，那麼高可用功能相當于沒有了！
此外，沒有主鍵引起的長時間的備庫延遲，我們的備份也隻能在主庫去做（否則資料是很久之前的），備份多多少少的還是要鎖表一段時間，影響主庫的可用性。
由于存量的無主鍵表，增加主鍵可能影響到業務邏輯，是以我們也提供了隐式主鍵功能，該功能現已預設開啟，但是存量表需要變更才能使用，新增表如果沒有提供主鍵預設增加一個隐式主鍵，保證row模式Binlog可以快速應用，有需要改動的可以咨詢阿裡雲售後。
避免大量集中單表操作
由于資料庫預設的并行複制功能是基于庫表級的并行複制（可參考我的上一篇文章，有介紹各版本并行複制功能），大量的單表操作同樣會造成不能并行複制的問題，進而影響備份以及HA等相關功能。
大事務（長時間查詢、資料變更）
根據mysql的設計，事務在送出時才會寫入binlog，較大的事務，例如執行1小時以上的事務，在完成後寫入binlog，從庫也需要1小時來完成binlog的應用，進而導緻這期間備庫延遲。在備庫延遲時，同樣會影響備份和HA相關功能。
大促前提前預估、規劃更新，保證執行個體磁盤、規格充裕，就是保住業務自己的生命線！
執行個體業務突然上量時，不僅僅是産生的資料會占用大量磁盤空間，由于除了資料本身，還會産生大量的Binlog，根據不同的binlog上傳、保留政策（可在控制台配置），可能會發生 binlog占用大量空間迅速讓執行個體空間滿鎖定的情況。
由于執行個體更新大部分情況下都需要做資料遷移（特别是本地盤的情況，資料搬遷會随着資料量大幅增加），此時進行執行個體更新，可能也不會特别順暢：業務壓力大時，如果優化不好可能會有嚴重的備庫延遲問題，追不上就沒辦法切換到更新後的新執行個體，屆時隻能停服停寫來完成更新，對業務的損失不可計量！
請在業務上量前，盡量評估好資料規模，至少提前一周更新RDS，并做好壓測，避免在業務高峰時更新升不上去，造成業務上的嚴重損失！
包年包月到期怎麼辦？
阿裡雲為盡最大可能保障您的資料，已經将執行個體過期後資料保留延長到15天，15天内都可以在控制台的資源回收筒功能中操作恢複，其中7天内續費可以秒恢複，7~15天可以通過備份恢複。假如您的資料比較敏感，也可以在資源回收筒功能中立即銷毀執行個體。