背景

去年的微盟“刪庫跑路”導致公司市值蒸發10億，前不久的網傳某互聯網公司實習生“刪庫”事件也上了頭條，到最近的巴西一個數據庫洩露近30T數據，影響2.2億人，關於數據庫安全的事件從未停止。

數據庫作為業務的數據核心，其安全及性能是所有企業都必須面對的問題。當企業上雲後，如何更加方便的監控雲上數據庫同樣是非常重要的一件事情。

如何更加快速的發現刪庫事件？

如何揪出惡意的登錄請求？

如何過濾性能需要優化的慢查詢？

。。。

RDS審計中心發佈後，讓問題變得簡單。

監控及告警

RDS審計中心內置最常見的一些告警規則（實際排查過程中可結合實際情況自行調整對應的參數及SQL查詢語句），參考RDS安全，具體告警設定參考設置告警，用戶可以聚焦於發現及解決問題本身。廢話不多說，我們直接看看一些常見的場景。

RDS慢SQL

當我們配置RDS慢SQL檢測後，如果一定時間範圍內觸發了告警，我們將通過配置的相應渠道接收到告警消息，比如郵件，

基於告警信息，我們直接通過RDS審計中心的審計性能中心查看慢SQL列表Top50，快速找出該異常時間段內的慢SQL語句，此處僅為測試樣例。

實際上，對於使用MySQL類關係型數據庫，讀操作是最多的，而讀操作裡的慢SQL也是最常見的問題，優化的空間及必要性都排在首位，大體可以分為三類：索引優化、SQL語句優化以及表優化，實際上也是一個相互關聯的持續優化過程。

索引優化也是最常見的場景，我們來看一個簡單的例子，如下，很顯然執行了全表掃描，where查詢條件的列沒有加索引。

我們加上索引後，查詢效果提升是非常顯著的

關於索引優化，遵循一些基本規則：

經常需要作為where查詢條件的列，建議增加索引，多個查詢條件可以增加複合索引
最左前綴匹配原則
選擇區分度儘可能高的列建索引
索引的列不能參與函數計算
如果可能通過擴展已有索引進行優化，則優先擴展索引，然後才是新建索引

關於SQL語句的優化，基本原則：

查詢儘量用具體字段，不用*
一般join性能優於子查詢，對於多表join，儘量用小表 join 大表
常用查詢可以考慮開啟緩存
尤其是對於查詢數據量非常大的情況，加上limit

關於表的優化，一般來說表的字段儘可能用NOT NULL，字段長度固定越有利於查詢，對於大表則需要結合業務進行水平或垂直拆分

總體來說，優化步驟如下：

首先利用好explain這個神器
瞭解查詢語句涉及到的表結構及相關索引信息
結合具體業務場景思考可能的優化點
驗證優化後的執行效果
重複以上步驟

RDS登錄失敗異常

當我們配置RDS登錄失敗次數過多告警後，如果一定時間範圍內觸發了告警，我們將通過配置的相應渠道接收到告警消息，比如郵件

基於告警信息，我們直接通過RDS審計中心的審計安全中心查看登錄失敗的IP統計，快速找出該異常時間段內頻繁嘗試登錄失敗的IP地址。

進一步地，我們可以點擊錯誤最多的客戶端列表框右上角，如下圖，查看分析詳情，基於告警的觸發時間往前選擇對應的時間間隔，定位具體IP地址，從而進一步評估是否將對應IP加入黑名單處理。

RDS刪除數據異常

當我們配置RDS大批量數據刪除告警，同樣在收到告警消息後，如下圖，通過RDS審計中心的審計安全中心，找到大批量刪除事件Top50列表框，也可以進一步查看分析詳情，選擇告警觸發時間段，選擇原始日誌，查看更多審計信息，快速定位對應時間段的異常刪除操作記錄，及時告警，避免有意、無意的刪除動作，最大限度的止損。