摘要：摘要阿里云主要分為離線分析和在線分析兩種功能。演講嘉賓簡介勛臣，阿里云內核團隊技術專家，目前阿里云專家系統開發。通過診斷報告定位性能下降原因。

摘要：阿里云CloudDBA主要分為離線分析和在線分析兩種功能。幫助用戶節省成本，定位問題，分析原因并推薦解決方法。CloudDBA可以做到實時診斷，離線診斷和SQL優化。并且通過MySQL的參數調優，檢測參數的不合理或者準備的延遲的情況。

演講嘉賓簡介：
勛臣，阿里云RDS內核團隊技術專家，目前阿里云CloudDBA專家系統開發。有著豐富的數據庫開發管理和優化的經驗。

PPT下載鏈接：http://click.aliyun.com/m/51146/
以下內容根據演講嘉賓視頻分享以及PPT整理而成。

本次的分享主要圍繞以下三個方面：

一、CloudDBA提供了什么
二、核心能力
三、典型實踐應用

一、CloudDBA提供了什么
CloudDBA主要提供了兩個功能，一個是離線分析，另一個是在線分析。我們知道DBA主要日常工作分為兩塊，一個是群檢，還有就是做線上的響應，比如說我的數據庫突然一下應用被卡住了，或者數據庫出現性能抖動，這些問題都是需要DBA實時響應的。Oracle包括兩個報告，一個是AWR報告，還有一個叫ASH報告，我們從功能上來說和Oracle有些類似。離線的分析主要是AWR報告，然后在線響應是ACTIVE SESS HISTORY。

CloudDBA在云上是SASS化的一塊，是基于PaaS平臺的增值服務。云上的SASS需要去解決性能的問題，問題的診斷，以及提供一些輔助的工具。云上的數據庫跟自建的數據庫有一點不同，如果數據庫上云了之后，PaaS這層的工作云都幫忙解決了。比如，性能監控，HA等都已經做了。DBA真正要做的是上面這一層，就是怎么讓數據庫運行的更好，讓用戶用好數據庫。

不管是云上的還是自建的數據庫，它本身的成本實際上是看得見的，是很低的。對做DBA的同學來說，從準備到數據庫上線花費的精力實際上是有限的。而真正的難點是如何把數據庫管理好？因為我們為做產品的平臺應用提供支撐，如果用戶的使用習慣不好，很容易將我們的數據庫搞壞掉，整個業務都會受到影響。所以從下圖可以看到我們的數據庫會有大量的維護成本，大概大于80%。當然DBA主要是解決應用中的一些問題，節省時間成本。比如說，用戶反饋說應用卡住了，對DBA來說需要登錄到數據庫中，到控制臺看動畫，看看到底發生了什么？這些動作實際上是很重復，很機械的、如果有CloudDBA，它會有自己的一些小的腳本，比如定位問題，很快的可以輸入用戶名密碼，把狀態抓出來，基于狀態做一些判斷。這種方式是可以的，但是還有更好的解決方式，如果作為一個產品，把這樣的行為產品化和服務化，交付出來。在應用卡住的時候，用戶只需要點一個按鈕，產品就可以把狀態抓出來，并且分析出數據庫卡住的點，并給出下一步的解決建議。甚至絕大部分場景，命令都會給生成出來，用戶直接復制執行就可以了。

二、核心能力

1.實時診斷
我們會把DBA積累的經驗產品化，編成程序，錄入到資料庫中去。將診斷的結果進行輸出。我們在日常工作當中會經常發現同樣的問題對不同的DBA來說解決的方式也不同。甚至說一位同學在當值班的時候遇到問題，知道怎么解決了，換另一位同學指班沒有遇到問題，過了很長的時間再一次發生時大家可能都忘了如何解決這個問題。所以這時就需要將工作經驗進行沉淀，產品化，服務化，再把它輸入出來。我們把解決問題的方法。技巧，經驗錄入到資料庫（Knowledge Base）中，它就是一個診斷程序，經過不斷的錄入經驗，Knowledge Base會變得越來越豐富。結果格式會分為現象描述，原因描述和相關診斷建議。

2.離線診斷
離線診斷是基于狀態，做深層次的分析，挖掘Top SQL，看哪些SQL執行次數最多，最長，消耗時間最長。另外還有事物分析，看事物是否合理，以及SQL Review。因為我們做DBA，如果沒有一個很強大的工具去規范開發人員行為的話，這個工具遲早會被拖垮。在早期的時候，出一份規范發給開發人員，要求搜索語句只能按照規范寫，否則會出事。但是如果沒有一個工具約束和規范，每個開發團隊都不可能看每一條規范語句。還有就是死鎖的分析。

3.SQL優化
MySQL的優化器當然沒有Qracle那么優秀，我們經常會聽到它的執行效果不是很好，表的連接順序不是那么的最優。比如表上面有索引，但是索引失效了，大家都知道索引失效的情況是字段不匹配。我們的工具會幫助我們在字段后面加個函數。比如說有一個交易表，交易表上有一個字段用時間去get，因為目前時間都至少精確到秒。很多開發人員會把日期函數直接加在get上面，等于具體某一天就可以了。但是如果用Oracle或者SQL Server3的數據庫是沒有問題的，DBA會給你加一個函數索引。但是如果用的是MySQL，而且是5.7之前的版本是沒有辦法的，真正的寫法是大于等于這一天的開始和小于等于這一天的結束，應該是這一天24小時的范圍之內都可以識別出來。還有一個是計算代價的重寫，我們會到備庫動態的采樣，比如說一個查詢，上面沒有索引，帶有多個字段，要建一個混合索引，那么這個字段的順序應該怎么放？我們會到備庫中動態采樣，看這些列上的數據分布，然后生成最優的字段順序，最優的索引。因為不可能看幾個字段有的所有索引順序，所以采取動態采樣。這一塊的內容可以到阿里云的官網搜，有很多非常詳細的資料和視頻。

三、最佳實踐
我們經常遇到用戶把規格升級，然后進行壓測，發現升級規格后性能反而下降。比如4C32G生級成了8C62G，發現吞吐下降。通過診斷報告TOP SQL定位性能下降原因。發現truncate的執行時間變慢了，為什么變慢?因為表的內存變多了，內存的張頁變多了，MySQL truncate之前是要把張頁落入文件里面去，利用我們的工具可以很快的定位原因語句，下一步應該把MySQL的 Max present的參數調小，把張塊控制在一定的范圍里面。

另外一個問題是用戶說每隔半小時就會出現壓力抖動，查明什么原因。因為用戶提出這個問題時，抖動發生的時間是在前幾天或者過了幾個小時。所以我們會建議用戶開啟CloudDBA，這樣才方便我們跟蹤，具體的數據用戶在自己的的控制臺就可以看到了。如下圖是通過TOP SQL得到的診斷報告，知道哪個時間發生了抖動。

連接滿了也分為不同的場景。第一種是出現鎖了，這種是最常見的，這是把鎖會話KILL掉。第二種就是在業務高空的時候執行了ddl的操作，這時也很好解決，我們都會幫助用戶定位出來。還有一種是應用程序的連接使用有問題，沒有關掉。比如Java的JDBC開了之后沒有關掉，這時我們也可以識別出來。我們會建議用戶使用連接池，及時的把連接關掉。還有一個，既不是MySQL堆積也不是鎖，也正常使用連接池，這時就可能是規格太小，壓力太大。如果不能升級規格，那么應用程序就要做限流。

連接滿了之后，CloudDBA可以幫助識別并終止會話。

CPU達到100%之后，CloudDBA可以幫忙識別出來，同時進行優化

除了上述的幾種場景，阿里還做了一些參數優化。MySQL有非常多的參數，參數的不合理或者準備的延遲都可以通過CloudDBA檢測出來。
CloudDBA是一個動態凈化的產品，我們是在不斷的更新。我們會和阿里云的工單系統聯系，他們處理的工單會扭轉到我們這邊，我們會吸收消化掉一部分，看哪些可以通過程序集成起來，RDBA會嵌在RDS數據庫的控制臺上面，用戶可以免費使用。

原文鏈接