宜信開源|性能優化利器：數據庫審覈平臺Themis的選型與實踐

時間 2019-11-13

原文原文鏈接

做者：韓鋒前端

出處：DBAplus社羣分享git

Themis開源地址：https://github.com/CreditEaseDBAgithub

拓展閱讀：宜信開源|數據庫審覈軟件Themis的規則解析與部署攻略正則表達式

【技術沙龍002期】數據中臺：宜信敏捷數據中臺建設實踐|宜信技術沙龍將於5月23日晚8點線上直播，點擊報名sql

1、面臨的挑戰

一、運維規模及種類

我相信，這也是不少公司、不少DBA正在面臨或將來都會面臨的一些問題。正是存在問題，促使咱們考慮引入數據庫審覈平臺。mongodb

首先是運維規模與人力資源之間的矛盾數據庫

從咱們的狀況來看，運維了包括Oracle、MySQL、MongoDB、Redis四類數據庫，數據庫規模幾十套，支持公司千餘名開發人員及上百套業務系統。也許有的朋友會問，從運維規模上看，並非很大。json

的確，與不少互聯網公司相比，數據庫數十套的估摸並非太大；但與互聯網類公司不一樣，相似宜信這類金融類公司對數據庫的依賴性更大，大量的應用是重數據庫類的，且其使用複雜程度也遠比互聯網類的複雜。DBA除了平常運維（這部分咱們也在經過自研平臺提高運維效率）外，還須要有大量精力應對數據庫設計、開發、優化類的工做。當面對大量的開發團隊須要服務時，這個矛盾就更加凸顯出來。緩存

二、案例

結構設計服務器

第二個挑戰，是數據庫設計、開發質量良莠不齊的問題

上圖就展現了一個結構設計問題。某核心系統的核心表，在這個系統運行的SQL中，28%都是跟這個對象有關的。當咱們分析其結構時，發現了不少的問題：

表的規模很大，從設計之初就沒有考慮到拆分邏輯（例如分庫、分表、分區設計），也沒有必要的數據庫清理、歸檔策略。
表存在100多個字段，字段數不少且不一樣字段使用特徵也不一致，沒有考慮到必要拆表設計。
表有13個索引，數目過多。表的索引過分，勢必會影響其DML效率。
還存在一個索引，在持續監控中發現，其從未被使用過。顯然這是一個「多餘」的索引。
還有兩個字段存在重複索引的現象，這也說明在創建索引之初是比較隨意的。
單個記錄定義長度爲5800多個字節，但實際其平均保存長度只有不到400字節，最大長度也不長。
分析其字段內容，還發現有3個字段類型定義異常。即沒有使用應有的類型保存數據，例如使用數字類型保存日期。

綜上所述，這個表設計的問題還有不少，並且這個表很是重要，大量語句訪問和其相關。

SQL語句

上圖展現的是一個語句運行效率的問題。從字面可見，兩個表作關聯查詢，但在指定條件時沒有指定關聯條件。在下面的執行計劃中可見，數據庫採用了笛卡爾積的方式運行。從後面的成本、估算時間等可見，這是一個多麼「巨大」的SQL。其在線上運行的影響，可想而知。

也許有人會說，這是一我的爲失誤，通常不會發生。但我要說的是，第一，人爲失誤沒法避免，誰也不能保證寫出SQL的運行質量；第二，開發人員對數據庫的理解不一樣，很難保證寫出的SQL都是高效的；第三，開發人員面臨大量業務需求，常常處理趕工狀態，很難有更多的精力放在優化上面。這由於有這些問題，線上語句執行質量就成了DBA常常面臨的挑戰之一。

三、重心轉移

這是一張很經典的圖，它描述了和數據庫相關工做的職能劃分。做爲DBA，除了面臨以上挑戰外，從數據庫工做發展階段及自身發展需求來看，也面臨一個重心的轉移：原有傳統DBA的運維職能逐步被弱化，大量的工具、平臺的涌現及數據庫自我運維能力的提高，簡化DBA的工做；緊隨而來的數據庫架構、結構設計、SQL質量優化逐步成爲重點；再往上層的數據治理、建模等工做也愈來愈受到一些公司的重視。因而可知，DBA將來工做的中心也逐步上移。對中間數據邏輯結構部分，也須要一些工具、平臺更好地支撐DBA的工做。

除上述狀況外，我司還存在幾種的不平衡。

從DBA平常工做來看，傳統運維工做仍是佔了較大的比重，而架構優化類則相對較少。經過引入這一平臺，能夠幫助DBA更方便地開展架構、優化類工做。
公司使用了較多的商業產品，而開源則使用較少。從公司長遠戰略來看，開源產品的使用會愈來愈多。從功能角度來看，商業產品相較於開源產品是有優點的。基於開源產品的軟件開發，對開發者自身技術技能要求更高。但願經過引入這一產品，能夠更容易完成這一轉型過程。
沒有平臺以前，DBA仍是大量經過手工方式設計、優化數據庫，其效率十分低下。特別是面對衆多產品線、衆多開發團隊時，每每感受力不從心。

公司自有團隊人員上，仍是以初中級爲主，中高級人員相對較少。如何快速提高總體設計、優化能力，保證統一的優化效果成爲擺在面前的問題。

正是有了上述多種的不平衡，促使咱們考慮引入工具、平臺去解決數據庫質量問題。

我剛來到公司時，看到公司的這些問題，也曾考慮經過制度、規範的形式進行解決。一開始就着手製定了不少的規範，而後在各個部門去培訓、宣講。這種方式運行一段時間後，暴露出一些問題：

總體效果改善並不明顯。實施效果取決於各個部門的重視程度及員工的我的能力。
規範落地效果沒法度量，也很難作到量化分析。每每只能經過上線運行結果來直觀感知。
缺少長期有效的跟蹤機制。沒法對具體某個系統長期跟蹤其運行質量。
從DBA的角度來看，面對大量的系統，很難依據每一個規範，詳細審覈其結構設計、SQL運行質量。

面臨上述這些挑戰、現存的各類問題，該如何解決？

通過討論，最後你們一致認爲，引入數據庫審覈平臺，能夠幫助解決上面所述問題。

2、平臺的選型

一、業內作法

在項目之初，我考察了業內其它企業是如何數據庫審覈的，大體可分爲三個思路：

第一類，是以BAT公司爲表明的互聯網類公司。它們經過自研的SQL引擎，可實現成本分析、自動審覈、訪問分流、限流等，可作到事前審覈、自動審覈。但技術難度較大，公司現有技術能力明顯不足。

第二類，是經過自研工具收集DB運行狀況，根據事前定義規則進行審覈，結合人工操做來完成整個審覈流程。這種方案只能作到過後審覈，但技術難度較小，靈活度很大。其核心就是規則集的制定，可根據狀況靈活擴展。

第三類，是一些商業產品，實現思路相似第二類，可是加上一些自主分析能力，功能更爲強大，但仍需人工介入處理且須要不小資金投入。並且考察幾款商業產品，沒有能徹底知足所需功能的。

綜合上面幾類作法，最終肯定咱們採用「工具+人工審覈」的方式，自研本身的審覈平臺。

二、咱們的選擇——自研

在啓動研發這一平臺之初，咱們就在團隊內部達成了一些共識。

DBA須要扭轉傳統運維的思想，每一個人都參與到平臺開發過程當中。
過去咱們積累的一些內容（例如前期制定的規範）能夠做爲知識庫沉澱下來，並標準化，這些爲後期規則的制定作好了鋪墊。
在平臺推動中，從最簡單的部分入手，開發好的就上線實施，觀察效果；根據實施效果，不斷修正後面的工做。
結合咱們自身的特色，定製目標；對於有些較複雜的部分，可果斷延後甚至放棄。
參考其它公司或商業產品的設計思想，大膽引入。

3、審覈平臺實踐

下面來看看，審覈平臺的基本功能及實現原理及方法，這部分是本次分享的重點。

一、平臺定位

在項目之初，咱們就平臺的定位作了描述：

平臺的核心能力是快速發現數據庫設計、SQL質量問題。
平臺只作過後審覈，自主優化部分放在二期實現。固然在項目設計階段引入這個，也能夠起到一部分事前審覈的功能。
經過Web界面完成所有工做，主要使用者是DBA和有必定數據庫基礎的研發人員。
可針對某個用戶審覈，可審覈包括數據結構、SQL文本、SQL執行特徵、SQL執行計劃等多個維度。
審覈結果經過Web頁面或導出文件的形式提供。
平臺需支持公司主流的Oracle、MySQL，其它數據庫放在二期實現。
儘可能提供靈活定製的能力，便於往後擴展功能。

二、平臺使用者

做爲平臺的兩類主要使用方，研發人員和DBA均可以從平臺中受益。

對於研發人員而言，只用這平臺可方便定位問題，及時進行修改；此外經過對規則的掌握，也能夠指導他們設計開發工做。
對於DBA而言，可快速掌握多個系統的總體狀況，批量篩選出低效SQL，並可經過平臺提供的信息快速診斷通常性問題。

三、實現原理

整個平臺的基本實現原理很簡單，就是將咱們的審覈對象（目前支持四種），經過規則集進行篩選。符合規則的審覈對象，都是疑似有問題的。平臺會將這些問題及關聯信息提供出來，供人工甄別使用。因而可知，平臺的功能強大與否，主要取決於規則集的豐富程度。平臺也提供了部分擴展能力，方便擴展規則集。

四、平臺設計

審覈對象

在開始介紹平臺實現以前，再來熟悉下「審覈對象」這個概念。目前咱們支持的有四類對象，分別說明一下。

對象級。這裏所說的對象就是指數據庫對象，常見的表、分區、索引、視圖、觸發器等等。典型規則，例如大表未分區等。
語句級。這裏所說的語句級，實際是指SQL語句文本自己。典型規則，例如多表關聯。
執行計劃級。這裏是指數據庫中SQL的執行計劃。典型規則，例如大表全表掃描。
執行特徵級。這裏是指語句在數據庫上的真實執行狀況。典型規則，例如掃描塊數與返回記錄比例太低。

須要說明一下，這四類審覈對象中，後三種必須在系統上線運行後纔會抓取到，第一種能夠在只有數據結構的狀況下運行(個別規則還須要有數據)。

此外，上述規則中，除了第二類爲通用規則外，其餘都與具體數據庫相關。即每種的數據庫，都有本身不一樣的規則。

架構簡圖

這裏畫出是系統架構框架簡圖，我簡單說明一下。

圖中的方框部分，爲平臺的主要模塊。底色不一樣的模塊，表示當前的進度狀態不一樣。虛線表明數據流，實線表明控制流。其核心爲這幾個模塊：

數據採集模塊。它是負責從數據源抓取審覈須要的基礎數據。目前支持從Oracle、MySQL抓取。
OBJ/SQL存儲庫。這是系統的共同存儲部分，採集的數據和處理過程當中的中間數據、結果數據都保存在這裏。其核心數據分爲對象類和SQL類。物理是採用的MongoDB。
核心管理模塊。圖中右側虛線部分包含的兩個模塊：SQL管理和OBJ管理就是這部分。它主要是完成對象的全生命週期管理。目前只作了簡單的對象過濾功能，所以仍是白色底色，核心的功能還沒有完成。
審覈規則和審覈引擎模塊。這部分是平臺一期的核心組件。審覈規則模塊是完成規則的定義、配置工做。審覈引擎模塊是完成具體規則的審覈執行部分。
優化規則和優化引擎模塊。這部分是平臺二期的核心組件。目前還沒有開發，所以爲白色底色。
系統管理模塊。這部分是完成平臺基礎功能，例如任務調度、空間管理、審覈報告生成、導出等功能。

流程圖

讓咱們從處理流程的角度，看看平臺的總體處理過程。

「規則管理」部分，這部分主要完成如下一些功能。

初始化規則。平臺自己內置了不少規則，在這一過程當中到導入到配置庫中。
新增規則。平臺自己提供了必定的擴展能力，能夠依據規範新增一條規則。
修改規則。能夠根據自身狀況開啓或關閉規則。對於每條規則，還內置了一些參數，也可在此處修改。此外，針對違反規則的狀況，還能夠設置扣分方法（例如違反一次扣幾分、最多可扣幾分）等。
規則自己及相關參數、配置信息等都會存儲在配置庫中。

「任務管理」部分，這是後臺管理的一個部分，主要完成與任務相關的工做。系統中的大多數交互都是經過做業異步完成的。其後臺是經過celery+flower實現的。
「數據採集」部分，這部分是經過任務調度定時出發採集做業完成，也有少許部分是實時查詢線上庫完成的。採集的結果保存在數據庫中，供後續分析部分調用。
「規則解析」部分，這部分是由用戶經過界面觸發，任務調度模塊會啓動一個後臺異步任務完成解析工做。之因此設計爲異步完成，主要是審覈工做可能時間較長（特別是選擇審覈類別較多、審覈對象不少、開啓的審覈規則較多）的狀況。審覈結果會保存在數據庫中。
「任務查看、導出」部分，在用戶發起審覈任務後，可在此部分查看進度（處於審覈中、仍是審覈完成）。當審覈完成後，可選擇審覈任務，瀏覽審覈結果或選擇導出都可。若是是選擇導出的話，會生成異步後臺做業生成文件，放置在下載服務器上。

以上就是整個審覈的大致流程。後續將看到各部分的詳細信息。

模塊劃分

總結一下，平臺主要是由上述四個模塊組成：數據採集、規則解析、系統管理、結果展現。後面將針對不一樣模塊的實現，進行詳細說明。

五、數據採集

採集內容

先來看看數據採集模塊。從表格可見，兩種類型數據庫的採集內容不一樣。

Oracle提供了較爲豐富的信息，須要的基本均可採集到；MySQL功能相對能採集到的信息較少。

表格中的「對號+星號」，表示非定時做業完成，而是後面實時回庫抓取的。下面簡單說下，各部分的採集內容。

對象級，採集了對象統計信息、存儲特徵、結構信息、訪問特徵。
SQL級，採集了SQL文本，執行計劃、緩存遊標、綁定變量、執行特徵等。

這些信息都將做爲後面審覈的依據。

採集原理

下面簡單介紹下采集的與原理：

Oracle部分，是經過定時做業採集的AWR數據，而後轉儲到一套MongoDB中。這裏跟有些相似產品不一樣，沒有直接採集內存中的數據，而是取自離線的數據。其目的是儘可能減小對線上運行的影響。Oracle提供的功能比較豐富，經過對AWR及數據字典的訪問，基本就能夠得到所有的數據。
MySQL部分，狀況就要複雜一些，緣由是其功能沒有那麼豐富。多類數據是經過不一樣源來獲取。SQL文本類及執行特徵類的，是經過pt工具分析慢查詢日誌定時入到Anemometer平臺庫，而後今後庫傳入MongoDB。其它類信息（包括數據字典類、執行計劃類等）是在須要時經過實時回庫查詢的。爲了防止影響主庫，通常是經過路由到從庫上執行得到的。

六、規則解析

概要說明

下面介紹整個系統最爲核心的部分—規則解析模塊，它所完成的功能是依據定義規則，審覈採集的數據，篩選出違反規則的數據。對篩選出的數據進行計分，並記錄下來供後續生成審覈報告使用。同時還會記錄附加信息，用於輔助進行一些判斷工做。

這裏有個核心的概念—「規則」。後面能夠看到一個內置規則的定義，你們就會比較清楚了。從分類來看，可大體分爲如下幾種。

從數據庫類型角度來區分，規則可分爲Oracle、MySQL。不是全部規則都區分數據庫，文本類的規則就不區分。
從複雜程度來區分，規則可分爲簡單規則和複雜規則。這裏所說的簡單和複雜，實際是指規則審覈的實現部分。簡單規則是能夠描述爲MongoDB或關係數據庫的一組查詢語句；而複雜規則是須要在外部經過程序體實現的。
從審覈對象角度來區分，規則可分爲對象類、文本類、執行計劃類和執行特徵類。下面會針對每類審覈對象，分別作說明。

規則定義

這是一個規則體的聲明對象，我說明一下各字段含義，你們也可對規則有個清晰的認識。

db_type：規則的數據庫類別，支持Oracle、MySQL。
input_parms：輸入參數。規則是能夠定義多個輸出參數，這是一個參數列表，每一個參數自身又是一個字典類，描述參數各類信息。
output_parms：輸出參數。相似上面的輸入參數，也是一個字典對象列表。描述了根據規則返回信息結構。
rule_complexity：規則是複雜規則仍是簡單規則。若是是簡單規則，則直接取rule_cmd內容做爲規則審覈的實現。若是是複雜規則，則是從外部定義的rule_name命令腳本中得到規則實現。
rule_cmd：規則的實現部分。規則多是mongodb的查詢語句、多是一個正則表達式，具體取決於rule_type。
rule_desc：規則描述，僅供顯示。
rule_name：規則名稱。是規則的惟一標識，全局惟一。
rule_status：規則狀態，ON或是OFF。對於關閉的規則，在審覈時會忽略它。
rule_summary：一個待廢棄的字段，意義同rule_desc。
rule_text：規則類型，分爲對象、文本、執行計劃、執行特徵四類。圖中的示例標識一個文本類型的規則，rule_cmd是正則表達式。
solution：觸發此規則的優化建議。
weight：權重，即單次違反規則的扣分制。
max_score：扣分上限，爲了不違反一個規則，產生過大影響，設置此參數。

規則定義（對象級）

先來看第一類規則—對象規則。這是針對數據庫對象設置的一組規則。上面表格，顯示了一些示例。常見的對象，諸如表、分區、索引、字段、函數、存儲過程、觸發器、約束、序列等都是審覈的對象。以表爲例，內置了不少規則。

例如：第一個的「大表過多」。表示一個數據庫中的大表個數超過規則定義閥值。這裏的大表又是經過規則輸入參數來肯定，參數包括表記錄數、表物理尺寸。總體描述這個規則就是「數據庫中超過指定尺寸或指定記錄數的表的個數超過規定閥值，則觸發審覈規則」。其它對象的規則也相似。

規則實現（對象級）

對象規則的實現部分，比較簡單。除個別規則外，基本都是對數據字典信息進行查詢，而後依據規則定義進行判斷。上面示例就是對索引的一個規則實現中，查詢數據字典信息。

規則定義（執行計劃級）

第二類規則是執行計劃類的規則，它也劃分爲若干類別。例如訪問路徑類、表間關聯類、類型轉換類、綁定變量類等。

以最爲常見的的訪問路徑類爲例，進行說明下。如最爲常見的一個規則「大表掃描」。它表示的是SQL語句的執行中，執行了對大表的訪問，而且訪問的路徑是採用全表掃描的方式。這個規則的輸入參數，包含了對大表的定義（物理大小或記錄數）；輸出部分則包括了表名、表大小及附加信息（包括整個執行計劃、指定大表的統計信息等內容）。

這類規則針對的數據源，是從線上數據庫中抓取的。Oracle部分是直接從AWR中按時間段提取的，MySQL部分是使用explain命令返查數據庫獲得的。

信息存儲格式

在這裏特別說明一下，在保存執行計劃的時候，使用了MongoDB這種文檔性數據庫。目的就是利用其schemaless特性，方便兼容不一樣數據庫、不一樣版本執行計劃的差別。均可以保存在一個集合中，後續的規則審覈也是利用的mongo中的查詢語句實現的。這也是最初引入mongo的初衷，後續也將其它類信息放入庫中。如今整個審覈平臺，除了pt工具接入的部分使用MySQL外，其他都在MongoDB中。此外，MySQL庫能夠直接輸出json格式的執行計劃，很方便就入庫了；Oracle部分也組成json格式入庫。

規則實現（執行計劃）

左邊就是一個Oracle的執行計劃保存在MongoDB中的樣子。其實就是將sqlplan字典數據插入到mongo中。右側就是一個規則實現的樣例，就是基於mongo的查詢語句。後面咱們會可看到一個詳細的示例。

七、平臺實現

規則實現

這裏以「大表全表掃描」規則爲例，進行說明。上面是在Oracle中的數據字典保存的執行計劃，下面是存在Mongo中的。可見，就是徹底複製下來的。

基於這樣的結構，如何實現規則過濾呢？其實就是經過mongo中的find語句實現的。下面具體解讀下這個語句的執行步驟。

最上面的find()部分，是用來過濾執行計劃的。將知足指定用戶、時間範圍、訪問路徑(「TABLE ACCESS」+」FULL」)的執行計劃篩選出來。
篩選出的部分，會關聯對象數據，將符合「大表」條件的部分篩選出來。大表規則是記錄數大於指定參數或者物理大小大於指定參數的。
取得的結果，將保存期sql_id、plan_hash_value、object_name信息返回。這三個信息將分別用於後續提取SQL語句信息、執行計劃信息、關聯對象信息使用。
取得的所有結果集，將按照先前設定的扣分原則，統計扣分。
提取到的三部分信息+扣分信息，將做爲結果返回，並在前端展現。

規則實現（執行計劃）

這部分是MySQL中實現層次結果存儲的一個實例。

第一個圖展現的是原始的執行計劃。

第二個圖是代碼實現的摘要。

第三個圖是真正保存在庫中的樣子。核心部分就是對item_level的生成。

規則定義（文本級）

第三類規則是文本類的規則，這是一類與數據庫種類無關、描述SQL語句文本特徵的規則。在實現上是採用文本正則匹配或程序方式進行處理的。它的主要目的是規範開發人員的SQL寫法，避免複雜的、性能較差的、不規範的SQL寫法。

規則實現（文本級）

這部分描述的是文本規則的實現方式。第一個示例bad_join，是一種簡單規則，經過正則文本匹配實現。第二個示例sub_query，是經過程序判斷括號嵌套來完成對子查詢(或多級子查詢)的判斷。

規則定義（執行特徵級）

最後一類規則是執行特徵類的。這部分是與數據庫緊密關聯的，將符合必定執行特徵的語句篩選出來。這些語句不必定是低效的，可能只是將來考慮優化的重點，或者說優化效益最高的一些語句。這裏面主要都是一些對資源的消耗狀況等。

八、系統管理

規則管理

後面經過一些界面展現，介紹下平臺的功能。

第一部分系統管理模塊中規則管理的部分。在這部分，可完成新增自有規則。其核心是規則實現部分，經過SQL語句、Mongo查詢語句、自定義Python文件的形式定義規則實現體。自定義規則的依據是現有抓取的數據源，定義者須要熟悉現有數據結構及含義。目前尚不支持自定義抓取數據源。

對定義好的規則，可在此處完成規則修改。主要是對規則狀態、閥值、扣分項等進行配置。

任務管理

在配置好規則後，可在此處完成任務發佈的工做。

上面是規則任務發佈的界面，在選擇數據源(ip、port、schema)後，選擇審覈類型及審覈日期。目前審覈數據源的定時策略仍是以天爲單位，所以日期不能選擇當天。

當任務發佈後，可在任務結果查看界面觀察執行狀況。根據審覈類型、數據源對象多少、語句多少等，審覈的時長不定，通常是在5分鐘之內。當審覈做業狀態爲「成功」時，表明審覈做業完成，能夠查看或導出審覈結果了。

九、結果展現

對象審覈結果概覽

上圖是一個對象審覈報告的示例。在報告的開頭部分，是一個概覽頁面。它集中展現審覈報告中各種規則及扣分狀況；並經過一個餅圖展現其佔比狀況。這便於咱們集中精力先處理核心問題。

在最上面，還能夠觀察到有一個規則總分的顯示。這是咱們將規則扣分按照百分制，折算後獲得的一個分數。分值越高，表明違反的狀況越少，審覈對象的質量越高。引入「規則總分」這一項，在設計之初是有些爭議的，擔憂有了這個指標會比較打擊開發人員的積極性，不利於平臺的推廣使用。這裏有幾點，說明一下。

引入規則總分，是爲了數據化數據庫設計、開發、運行質量。以往在不少優化中，很難去量化優化先後的效果。這裏提供了一種手段去作先後對比。可能這個方式不是太科學的，可是畢竟提供一種可量化的手段。
各業務系統差別較大，沒有必要作橫向對比。A系統60分，B系統50分，不表明A的質量就比B的質量高。
單一系統可多作縱向對比，即對比改造優化先後的規則總分。可在必定程度上反映出系統質量的變化。
規則總分，跟規則配置關係很大。如關閉規則或將違反規則的閥值調低，都會提升分數。這要根據系統自身狀況來肯定。同一規則，對不一樣系統使用，其閥值是能夠不一樣的。舉例而言，數據倉庫類的應用，大表所有掃描就是一個比較正常的行爲，可考慮關閉此規則或將單次違反閥值、總扣分上限下降。

對象審覈結果明細

這部分是對象審覈的明細部分，對應每一個規則其詳細狀況，可在左側連接中進一步查看對象信息。篇幅所限，不作展現了。

執行計劃審覈結果概覽

這部分執行計劃的概覽展現，跟對象的狀況相似。也是每種規則的扣分狀況。

執行計劃審覈結果明細

這部分是執行計劃的明細部分。

展開以後，能夠看到違反每種規則的明細。上圖就是違反全表掃描的規則的明細部分。

在上面是一些通用的解決方案說明。這裏將可能觸發此類規則的狀況及解決方案進行了說明。至關於一個小知識庫，便於開發人員優化。後面在平臺二期，會作更爲精準的優化引擎部分，這部分還會展開。

下面是每條違反的語句狀況，咱們能夠看到語句文本、執行計劃、關聯信息（例如此規則的大表名稱）等。還能夠進一步點開語句，展開信息。

這部分是針對每條SQL的信息，包括語句文本、執行計劃、執行特徵、關聯對象統計信息等。DBA可從這些信息就能夠作一些初步的優化判斷工做。

此外，平臺也提供了導出功能。可導出爲excel文件，供用戶下載查看。這裏就展現了。