作者：韓鋒
創(chuàng)新互聯(lián)建站主要從事網(wǎng)站制作、網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)木壘哈薩克,十余年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792出處：DBAplus社群分享
Themis開源地址：https://github.com/CreditEaseDBA
拓展閱讀：宜信開源|數(shù)據(jù)庫審核軟件Themis的規(guī)則解析與部署攻略
【技術(shù)沙龍002期】數(shù)據(jù)中臺：宜信敏捷數(shù)據(jù)中臺建設(shè)實踐|宜信技術(shù)沙龍 將于5月23日晚8點線上直播，點擊報名
我相信，這也是很多公司、很多DBA正在面臨或未來都會面臨的一些問題。正是存在問題，促使我們考慮引入數(shù)據(jù)庫審核平臺。
首先是運維規(guī)模與人力資源之間的矛盾。從我們的情況來看，運維了包括Oracle、MySQL、MongoDB、Redis四類數(shù)據(jù)庫，數(shù)據(jù)庫規(guī)模幾十套，支持公司千余名開發(fā)人員及上百套業(yè)務(wù)系統(tǒng)。也許有的朋友會問，從運維規(guī)模上看，并不是很大。
的確，與很多互聯(lián)網(wǎng)公司相比，數(shù)據(jù)庫數(shù)十套的估摸并不是太大；但與互聯(lián)網(wǎng)類公司不同，類似宜信這類金融類公司對數(shù)據(jù)庫的依賴性更大，大量的應(yīng)用是重數(shù)據(jù)庫類的，且其使用復(fù)雜程度也遠(yuǎn)比互聯(lián)網(wǎng)類的復(fù)雜。DBA除了日常運維（這部分我們也在通過自研平臺提升運維效率）外，還需要有大量精力應(yīng)對數(shù)據(jù)庫設(shè)計、開發(fā)、優(yōu)化類的工作。當(dāng)面對大量的開發(fā)團(tuán)隊需要服務(wù)時，這個矛盾就更加凸顯出來。
結(jié)構(gòu)設(shè)計
第二個挑戰(zhàn)，是數(shù)據(jù)庫設(shè)計、開發(fā)質(zhì)量參差不齊的問題。 上圖就展示了一個結(jié)構(gòu)設(shè)計問題。某核心系統(tǒng)的核心表，在這個系統(tǒng)運行的SQL中，28%都是跟這個對象有關(guān)的。當(dāng)我們分析其結(jié)構(gòu)時，發(fā)現(xiàn)了很多的問題：
綜上所述，這個表設(shè)計的問題還有很多，而且這個表非常重要，大量語句訪問和其相關(guān)。
SQL語句
上圖展示的是一個語句運行效率的問題。從字面可見，兩個表做關(guān)聯(lián)查詢，但在指定條件時沒有指定關(guān)聯(lián)條件。在下面的執(zhí)行計劃中可見，數(shù)據(jù)庫采用了笛卡爾積的方式運行。從后面的成本、估算時間等可見，這是一個多么“巨大”的SQL。其在線上運行的影響，可想而知。
也許有人會說，這是一個人為失誤，一般不會發(fā)生。但我要說的是，第一，人為失誤無法避免，誰也不能保證寫出SQL的運行質(zhì)量；第二，開發(fā)人員對數(shù)據(jù)庫的理解不同，很難保證寫出的SQL都是高效的；第三，開發(fā)人員面臨大量業(yè)務(wù)需求，經(jīng)常處理趕工狀態(tài)，很難有更多的精力放在優(yōu)化上面。這因為有這些問題，線上語句執(zhí)行質(zhì)量就成了DBA經(jīng)常面臨的挑戰(zhàn)之一。
這是一張很經(jīng)典的圖，它描述了和數(shù)據(jù)庫相關(guān)工作的職能劃分。作為DBA，除了面臨以上挑戰(zhàn)外，從數(shù)據(jù)庫工作發(fā)展階段及自身發(fā)展需求來看，也面臨一個重心的轉(zhuǎn)移：原有傳統(tǒng)DBA的運維職能逐步被弱化，大量的工具、平臺的涌現(xiàn)及數(shù)據(jù)庫自我運維能力的提升，簡化DBA的工作；緊隨而來的數(shù)據(jù)庫架構(gòu)、結(jié)構(gòu)設(shè)計、SQL質(zhì)量優(yōu)化逐步成為重點；再往上層的數(shù)據(jù)治理、建模等工作也越來越受到一些公司的重視。由此可見，DBA未來工作的中心也逐步上移。對中間數(shù)據(jù)邏輯結(jié)構(gòu)部分，也需要一些工具、平臺更好地支撐DBA的工作。
除上述情況外，我司還存在幾種的不平衡。
從DBA日常工作來看，傳統(tǒng)運維工作還是占了較大的比重，而架構(gòu)優(yōu)化類則相對較少。通過引入這一平臺，可以幫助DBA更方便地開展架構(gòu)、優(yōu)化類工作。
公司使用了較多的商業(yè)產(chǎn)品，而開源則使用較少。從公司長遠(yuǎn)戰(zhàn)略來看，開源產(chǎn)品的使用會越來越多。從功能角度來看，商業(yè)產(chǎn)品相較于開源產(chǎn)品是有優(yōu)勢的。基于開源產(chǎn)品的軟件開發(fā)，對開發(fā)者自身技術(shù)技能要求更高。希望通過引入這一產(chǎn)品，可以更容易完成這一轉(zhuǎn)型過程。
公司自有團(tuán)隊人員上，還是以初中級為主，中高級人員相對較少。如何快速提升整體設(shè)計、優(yōu)化能力，保證統(tǒng)一的優(yōu)化效果成為擺在面前的問題。
正是有了上述多種的不平衡，促使我們考慮引入工具、平臺去解決數(shù)據(jù)庫質(zhì)量問題。
我剛來到公司時，看到公司的這些問題，也曾考慮通過制度、規(guī)范的形式進(jìn)行解決。一開始就著手制定了很多的規(guī)范，然后在各個部門去培訓(xùn)、宣講。這種方式運行一段時間后，暴露出一些問題：
整體效果改善并不明顯。實施效果取決于各個部門的重視程度及員工的個人能力。
規(guī)范落地效果無法度量，也很難做到量化分析。往往只能通過上線運行結(jié)果來直觀感知。
缺乏長期有效的跟蹤機制。無法對具體某個系統(tǒng)長期跟蹤其運行質(zhì)量。
面臨上述這些挑戰(zhàn)、現(xiàn)存的各種問題，該如何解決？
經(jīng)過討論，最后大家一致認(rèn)為，引入數(shù)據(jù)庫審核平臺，可以幫助解決上面所述問題。
在項目之初，我考察了業(yè)內(nèi)其它企業(yè)是如何數(shù)據(jù)庫審核的，大致可分為三個思路：
第一類，是以BAT公司為代表的互聯(lián)網(wǎng)類公司。它們通過自研的SQL引擎，可實現(xiàn)成本分析、自動審核、訪問分流、限流等，可做到事前審核、自動審核。但技術(shù)難度較大，公司現(xiàn)有技術(shù)能力明顯不足。
第二類，是通過自研工具收集DB運行情況，根據(jù)事前定義規(guī)則進(jìn)行審核，結(jié)合人工操作來完成整個審核流程。這種方案只能做到事后審核，但技術(shù)難度較小，靈活度很大。其核心就是規(guī)則集的制定，可根據(jù)情況靈活擴展。
第三類，是一些商業(yè)產(chǎn)品，實現(xiàn)思路類似第二類，但是加上一些自主分析能力，功能更為強大，但仍需人工介入處理且需要不小資金投入。而且考察幾款商業(yè)產(chǎn)品，沒有能完全滿足所需功能的。
綜合上面幾類做法，最終確定我們采用“工具+人工審核”的方式，自研自己的審核平臺。
在啟動研發(fā)這一平臺之初，我們就在團(tuán)隊內(nèi)部達(dá)成了一些共識。
DBA需要扭轉(zhuǎn)傳統(tǒng)運維的思想，每個人都參與到平臺開發(fā)過程中。
過去我們積累的一些內(nèi)容（例如前期制定的規(guī)范）可以作為知識庫沉淀下來，并標(biāo)準(zhǔn)化，這些為后期規(guī)則的制定做好了鋪墊。
在平臺推進(jìn)中，從最簡單的部分入手，開發(fā)好的就上線實施，觀察效果；根據(jù)實施效果，不斷修正后面的工作。
結(jié)合我們自身的特點，定制目標(biāo)；對于有些較復(fù)雜的部分，可果斷延后甚至放棄。
下面來看看，審核平臺的基本功能及實現(xiàn)原理及方法，這部分是本次分享的重點。
在項目之初，我們就平臺的定位做了描述：
平臺的核心能力是快速發(fā)現(xiàn)數(shù)據(jù)庫設(shè)計、SQL質(zhì)量問題。
平臺只做事后審核，自主優(yōu)化部分放在二期實現(xiàn)。當(dāng)然在項目設(shè)計階段引入這個，也可以起到一部分事前審核的功能。
通過Web界面完成全部工作，主要使用者是DBA和有一定數(shù)據(jù)庫基礎(chǔ)的研發(fā)人員。
可針對某個用戶審核，可審核包括數(shù)據(jù)結(jié)構(gòu)、SQL文本、SQL執(zhí)行特征、SQL執(zhí)行計劃等多個維度。
審核結(jié)果通過Web頁面或?qū)С鑫募男问教峁?/p>
平臺需支持公司主流的Oracle、MySQL，其它數(shù)據(jù)庫放在二期實現(xiàn)。
作為平臺的兩類主要使用方，研發(fā)人員和DBA都可以從平臺中受益。
對于研發(fā)人員而言，只用這平臺可方便定位問題，及時進(jìn)行修改；此外通過對規(guī)則的掌握，也可以指導(dǎo)他們設(shè)計開發(fā)工作。
整個平臺的基本實現(xiàn)原理很簡單，就是將我們的審核對象（目前支持四種），通過規(guī)則集進(jìn)行篩選。符合規(guī)則的審核對象，都是疑似有問題的。平臺會將這些問題及關(guān)聯(lián)信息提供出來，供人工甄別使用。由此可見，平臺的功能強大與否，主要取決于規(guī)則集的豐富程度。平臺也提供了部分?jǐn)U展能力，方便擴展規(guī)則集。
審核對象
在開始介紹平臺實現(xiàn)之前，再來熟悉下“審核對象”這個概念。目前我們支持的有四類對象，分別說明一下。
對象級。這里所說的對象就是指數(shù)據(jù)庫對象，常見的表、分區(qū)、索引、視圖、觸發(fā)器等等。典型規(guī)則，例如大表未分區(qū)等。
語句級。這里所說的語句級，實際是指SQL語句文本本身。典型規(guī)則，例如多表關(guān)聯(lián)。
執(zhí)行計劃級。這里是指數(shù)據(jù)庫中SQL的執(zhí)行計劃。典型規(guī)則，例如大表全表掃描。
需要說明一下，這四類審核對象中，后三種必須在系統(tǒng)上線運行后才會抓取到，第一種可以在只有數(shù)據(jù)結(jié)構(gòu)的情況下運行(個別規(guī)則還需要有數(shù)據(jù))。
此外，上述規(guī)則中，除了第二類為通用規(guī)則外，其他都與具體數(shù)據(jù)庫相關(guān)。即每種的數(shù)據(jù)庫，都有自己不同的規(guī)則。
架構(gòu)簡圖
這里畫出是系統(tǒng)架構(gòu)框架簡圖，我簡單說明一下。
圖中的方框部分，為平臺的主要模塊。底色不同的模塊，表示當(dāng)前的進(jìn)度狀態(tài)不同。虛線代表數(shù)據(jù)流，實線代表控制流。其核心為這幾個模塊：
數(shù)據(jù)采集模塊。它是負(fù)責(zé)從數(shù)據(jù)源抓取審核需要的基礎(chǔ)數(shù)據(jù)。目前支持從Oracle、MySQL抓取。
OBJ/SQL存儲庫。這是系統(tǒng)的共同存儲部分，采集的數(shù)據(jù)和處理過程中的中間數(shù)據(jù)、結(jié)果數(shù)據(jù)都保存在這里。其核心數(shù)據(jù)分為對象類和SQL類。物理是采用的MongoDB。
核心管理模塊。圖中右側(cè)虛線部分包含的兩個模塊：SQL管理和OBJ管理就是這部分。它主要是完成對象的全生命周期管理。目前只做了簡單的對象過濾功能，因此還是白色底色，核心的功能尚未完成。
審核規(guī)則和審核引擎模塊。這部分是平臺一期的核心組件。審核規(guī)則模塊是完成規(guī)則的定義、配置工作。審核引擎模塊是完成具體規(guī)則的審核執(zhí)行部分。
優(yōu)化規(guī)則和優(yōu)化引擎模塊。這部分是平臺二期的核心組件。目前尚未開發(fā)，因此為白色底色。
流程圖
讓我們從處理流程的角度，看看平臺的整體處理過程。
1) “規(guī)則管理”部分，這部分主要完成以下一些功能。
初始化規(guī)則。平臺本身內(nèi)置了很多規(guī)則，在這一過程中到導(dǎo)入到配置庫中。
新增規(guī)則。平臺本身提供了一定的擴展能力，可以依據(jù)規(guī)范新增一條規(guī)則。
修改規(guī)則。可以根據(jù)自身情況開啟或關(guān)閉規(guī)則。對于每條規(guī)則，還內(nèi)置了一些參數(shù)，也可在此處修改。此外，針對違反規(guī)則的情況，還可以設(shè)置扣分方法（例如違反一次扣幾分、最多可扣幾分）等。
2) “任務(wù)管理”部分，這是后臺管理的一個部分，主要完成與任務(wù)相關(guān)的工作。系統(tǒng)中的大多數(shù)交互都是通過作業(yè)異步完成的。其后臺是通過celery+flower實現(xiàn)的。
3) “數(shù)據(jù)采集”部分，這部分是通過任務(wù)調(diào)度定時出發(fā)采集作業(yè)完成，也有少量部分是實時查詢線上庫完成的。采集的結(jié)果保存在數(shù)據(jù)庫中，供后續(xù)分析部分調(diào)用。
4) “規(guī)則解析”部分，這部分是由用戶通過界面觸發(fā)，任務(wù)調(diào)度模塊會啟動一個后臺異步任務(wù)完成解析工作。之所以設(shè)計為異步完成，主要是審核工作可能時間較長（特別是選擇審核類別較多、審核對象很多、開啟的審核規(guī)則較多）的情況。審核結(jié)果會保存在數(shù)據(jù)庫中。
5) “任務(wù)查看、導(dǎo)出”部分，在用戶發(fā)起審核任務(wù)后，可在此部分查看進(jìn)度（處于審核中、還是審核完成）。當(dāng)審核完成后，可選擇審核任務(wù)，瀏覽審核結(jié)果或選擇導(dǎo)出均可。如果是選擇導(dǎo)出的話，會生成異步后臺作業(yè)生成文件，放置在下載服務(wù)器上。
以上就是整個審核的大體流程。后續(xù)將看到各部分的詳細(xì)信息。
模塊劃分
總結(jié)一下，平臺主要是由上述四個模塊組成：數(shù)據(jù)采集、規(guī)則解析、系統(tǒng)管理、結(jié)果展示。后面將針對不同模塊的實現(xiàn)，進(jìn)行詳細(xì)說明。
采集內(nèi)容
先來看看數(shù)據(jù)采集模塊。從表格可見，兩種類型數(shù)據(jù)庫的采集內(nèi)容不同。
Oracle提供了較為豐富的信息，需要的基本都可采集到；MySQL功能相對能采集到的信息較少。
表格中的“對號+星號”，表示非定時作業(yè)完成，而是后面實時回庫抓取的。下面簡單說下，各部分的采集內(nèi)容。
對象級，采集了對象統(tǒng)計信息、存儲特征、結(jié)構(gòu)信息、訪問特征。
這些信息都將作為后面審核的依據(jù)。
采集原理
下面簡單介紹下采集的與原理：
Oracle部分，是通過定時作業(yè)采集的AWR數(shù)據(jù)，然后轉(zhuǎn)儲到一套MongoDB中。這里跟有些類似產(chǎn)品不同，沒有直接采集內(nèi)存中的數(shù)據(jù)，而是取自離線的數(shù)據(jù)。其目的是盡量減少對線上運行的影響。Oracle提供的功能比較豐富，通過對AWR及數(shù)據(jù)字典的訪問，基本就可以獲得全部的數(shù)據(jù)。
概要說明
下面介紹整個系統(tǒng)最為核心的部分—規(guī)則解析模塊，它所完成的功能是依據(jù)定義規(guī)則，審核采集的數(shù)據(jù)，篩選出違反規(guī)則的數(shù)據(jù)。對篩選出的數(shù)據(jù)進(jìn)行計分，并記錄下來供后續(xù)生成審核報告使用。同時還會記錄附加信息，用于輔助進(jìn)行一些判斷工作。
這里有個核心的概念—“規(guī)則”。后面可以看到一個內(nèi)置規(guī)則的定義，大家就會比較清楚了。從分類來看，可大致分為以下幾種。
從數(shù)據(jù)庫類型角度來區(qū)分，規(guī)則可分為Oracle、MySQL。不是所有規(guī)則都區(qū)分?jǐn)?shù)據(jù)庫，文本類的規(guī)則就不區(qū)分。
從復(fù)雜程度來區(qū)分，規(guī)則可分為簡單規(guī)則和復(fù)雜規(guī)則。這里所說的簡單和復(fù)雜，實際是指規(guī)則審核的實現(xiàn)部分。簡單規(guī)則是可以描述為MongoDB或關(guān)系數(shù)據(jù)庫的一組查詢語句；而復(fù)雜規(guī)則是需要在外部通過程序體實現(xiàn)的。
規(guī)則定義
這是一個規(guī)則體的聲明對象，我說明一下各字段含義，大家也可對規(guī)則有個清晰的認(rèn)識。
db_type：規(guī)則的數(shù)據(jù)庫類別，支持Oracle、MySQL。
input_parms：輸入?yún)?shù)。規(guī)則是可以定義多個輸出參數(shù)，這是一個參數(shù)列表，每個參數(shù)自身又是一個字典類，描述參數(shù)各種信息。
output_parms：輸出參數(shù)。類似上面的輸入?yún)?shù)，也是一個字典對象列表。描述了根據(jù)規(guī)則返回信息結(jié)構(gòu)。
rule_complexity：規(guī)則是復(fù)雜規(guī)則還是簡單規(guī)則。如果是簡單規(guī)則，則直接取rule_cmd內(nèi)容作為規(guī)則審核的實現(xiàn)。如果是復(fù)雜規(guī)則，則是從外部定義的rule_name命令腳本中獲得規(guī)則實現(xiàn)。
rule_cmd：規(guī)則的實現(xiàn)部分。規(guī)則可能是mongodb的查詢語句、可能是一個正則表達(dá)式，具體取決于rule_type。
rule_desc：規(guī)則描述，僅供顯示。
rule_name：規(guī)則名稱。是規(guī)則的唯一標(biāo)識，全局唯一。
rule_status：規(guī)則狀態(tài)，ON或是OFF。對于關(guān)閉的規(guī)則，在審核時會忽略它。
rule_summary：一個待廢棄的字段，意義同rule_desc。
rule_text：規(guī)則類型，分為對象、文本、執(zhí)行計劃、執(zhí)行特征四類。圖中的示例標(biāo)識一個文本類型的規(guī)則，rule_cmd是正則表達(dá)式。
solution：觸發(fā)此規(guī)則的優(yōu)化建議。
weight：權(quán)重，即單次違反規(guī)則的扣分制。
規(guī)則定義（對象級）
先來看第一類規(guī)則—對象規(guī)則。這是針對數(shù)據(jù)庫對象設(shè)置的一組規(guī)則。上面表格，顯示了一些示例。常見的對象，諸如表、分區(qū)、索引、字段、函數(shù)、存儲過程、觸發(fā)器、約束、序列等都是審核的對象。以表為例，內(nèi)置了很多規(guī)則。
例如：第一個的“大表過多”。表示一個數(shù)據(jù)庫中的大表個數(shù)超過規(guī)則定義閥值。這里的大表又是通過規(guī)則輸入?yún)?shù)來確定，參數(shù)包括表記錄數(shù)、表物理尺寸。整體描述這個規(guī)則就是“數(shù)據(jù)庫中超過指定尺寸或指定記錄數(shù)的表的個數(shù)超過規(guī)定閥值，則觸發(fā)審核規(guī)則”。其它對象的規(guī)則也類似。
規(guī)則實現(xiàn)（對象級）
對象規(guī)則的實現(xiàn)部分，比較簡單。除個別規(guī)則外，基本都是對數(shù)據(jù)字典信息進(jìn)行查詢，然后依據(jù)規(guī)則定義進(jìn)行判斷。上面示例就是對索引的一個規(guī)則實現(xiàn)中，查詢數(shù)據(jù)字典信息。
規(guī)則定義（執(zhí)行計劃級）
第二類規(guī)則是執(zhí)行計劃類的規(guī)則，它也劃分為若干類別。例如訪問路徑類、表間關(guān)聯(lián)類、類型轉(zhuǎn)換類、綁定變量類等。
以最為常見的的訪問路徑類為例，進(jìn)行說明下。如最為常見的一個規(guī)則“大表掃描”。它表示的是SQL語句的執(zhí)行中，執(zhí)行了對大表的訪問，并且訪問的路徑是采用全表掃描的方式。這個規(guī)則的輸入?yún)?shù)，包含了對大表的定義（物理大小或記錄數(shù)）；輸出部分則包括了表名、表大小及附加信息（包括整個執(zhí)行計劃、指定大表的統(tǒng)計信息等內(nèi)容）。
這類規(guī)則針對的數(shù)據(jù)源，是從線上數(shù)據(jù)庫中抓取的。Oracle部分是直接從AWR中按時間段提取的，MySQL部分是使用explain命令返查數(shù)據(jù)庫得到的。
信息存儲格式
在這里特別說明一下，在保存執(zhí)行計劃的時候，使用了MongoDB這種文檔性數(shù)據(jù)庫。目的就是利用其schemaless特性，方便兼容不同數(shù)據(jù)庫、不同版本執(zhí)行計劃的差異。都可以保存在一個集合中，后續(xù)的規(guī)則審核也是利用的mongo中的查詢語句實現(xiàn)的。這也是最初引入mongo的初衷，后續(xù)也將其它類信息放入庫中。現(xiàn)在整個審核平臺，除了pt工具接入的部分使用MySQL外，其余都在MongoDB中。此外，MySQL庫可以直接輸出json格式的執(zhí)行計劃，很方便就入庫了；Oracle部分也組成json格式入庫。
規(guī)則實現(xiàn)（執(zhí)行計劃）
左邊就是一個Oracle的執(zhí)行計劃保存在MongoDB中的樣子。其實就是將sqlplan字典數(shù)據(jù)插入到mongo中。右側(cè)就是一個規(guī)則實現(xiàn)的樣例，就是基于mongo的查詢語句。后面我們會可看到一個詳細(xì)的示例。
規(guī)則實現(xiàn)
這里以“大表全表掃描”規(guī)則為例，進(jìn)行說明。上面是在Oracle中的數(shù)據(jù)字典保存的執(zhí)行計劃，下面是存在Mongo中的?？梢姡褪峭耆珡?fù)制下來的。
基于這樣的結(jié)構(gòu)，如何實現(xiàn)規(guī)則過濾呢？其實就是通過mongo中的find語句實現(xiàn)的。下面具體解讀下這個語句的執(zhí)行步驟。
最上面的find()部分，是用來過濾執(zhí)行計劃的。將滿足指定用戶、時間范圍、訪問路徑(“TABLE ACCESS”+”FULL”)的執(zhí)行計劃篩選出來。
篩選出的部分，會關(guān)聯(lián)對象數(shù)據(jù)，將符合“大表”條件的部分篩選出來。大表規(guī)則是記錄數(shù)大于指定參數(shù)或者物理大小大于指定參數(shù)的。
取得的結(jié)果，將保存期sql_id、plan_hash_value、object_name信息返回。這三個信息將分別用于后續(xù)提取SQL語句信息、執(zhí)行計劃信息、關(guān)聯(lián)對象信息使用。
取得的全部結(jié)果集，將按照先前設(shè)定的扣分原則，統(tǒng)計扣分。
規(guī)則實現(xiàn)（執(zhí)行計劃）
這部分是MySQL中實現(xiàn)層次結(jié)果存儲的一個實例。
第一個圖展示的是原始的執(zhí)行計劃。
第二個圖是代碼實現(xiàn)的摘要。
第三個圖是真正保存在庫中的樣子。核心部分就是對item_level的生成。
規(guī)則定義（文本級）
第三類規(guī)則是文本類的規(guī)則，這是一類與數(shù)據(jù)庫種類無關(guān)、描述SQL語句文本特征的規(guī)則。在實現(xiàn)上是采用文本正則匹配或程序方式進(jìn)行處理的。它的主要目的是規(guī)范開發(fā)人員的SQL寫法，避免復(fù)雜的、性能較差的、不規(guī)范的SQL寫法。
規(guī)則實現(xiàn)（文本級）
這部分描述的是文本規(guī)則的實現(xiàn)方式。第一個示例bad_join，是一種簡單規(guī)則，通過正則文本匹配實現(xiàn)。第二個示例sub_query，是通過程序判斷括號嵌套來完成對子查詢(或多級子查詢)的判斷。
規(guī)則定義（執(zhí)行特征級）
最后一類規(guī)則是執(zhí)行特征類的。這部分是與數(shù)據(jù)庫緊密關(guān)聯(lián)的，將符合一定執(zhí)行特征的語句篩選出來。這些語句不一定是低效的，可能只是未來考慮優(yōu)化的重點，或者說優(yōu)化效益高的一些語句。這里面主要都是一些對資源的消耗情況等。
規(guī)則管理
后面通過一些界面展示，介紹下平臺的功能。
第一部分系統(tǒng)管理模塊中規(guī)則管理的部分。在這部分，可完成新增自有規(guī)則。其核心是規(guī)則實現(xiàn)部分，通過SQL語句、Mongo查詢語句、自定義Python文件的形式定義規(guī)則實現(xiàn)體。自定義規(guī)則的依據(jù)是現(xiàn)有抓取的數(shù)據(jù)源，定義者需要熟悉現(xiàn)有數(shù)據(jù)結(jié)構(gòu)及含義。目前尚不支持自定義抓取數(shù)據(jù)源。
對定義好的規(guī)則，可在此處完成規(guī)則修改。主要是對規(guī)則狀態(tài)、閥值、扣分項等進(jìn)行配置。
任務(wù)管理
在配置好規(guī)則后，可在此處完成任務(wù)發(fā)布的工作。
上面是規(guī)則任務(wù)發(fā)布的界面，在選擇數(shù)據(jù)源(ip、port、schema)后，選擇審核類型及審核日期。目前審核數(shù)據(jù)源的定時策略還是以天為單位，因此日期不能選擇當(dāng)天。
當(dāng)任務(wù)發(fā)布后，可在任務(wù)結(jié)果查看界面觀察執(zhí)行情況。根據(jù)審核類型、數(shù)據(jù)源對象多少、語句多少等，審核的時長不定，一般是在5分鐘以內(nèi)。當(dāng)審核作業(yè)狀態(tài)為“成功”時，代表審核作業(yè)完成，可以查看或?qū)С鰧徍私Y(jié)果了。
對象審核結(jié)果概覽
上圖是一個對象審核報告的示例。在報告的開頭部分，是一個概覽頁面。它集中展示審核報告中各類規(guī)則及扣分情況；并通過一個餅圖展示其占比情況。這便于我們集中精力先處理核心問題。
在最上面，還可以觀察到有一個規(guī)則總分的顯示。這是我們將規(guī)則扣分按照百分制，折算后得到的一個分?jǐn)?shù)。分值越高，代表違反的情況越少，審核對象的質(zhì)量越高。引入“規(guī)則總分”這一項，在設(shè)計之初是有些爭議的，擔(dān)心有了這個指標(biāo)會比較打擊開發(fā)人員的積極性，不利于平臺的推廣使用。這里有幾點，說明一下。
引入規(guī)則總分，是為了數(shù)據(jù)化數(shù)據(jù)庫設(shè)計、開發(fā)、運行質(zhì)量。以往在很多優(yōu)化中，很難去量化優(yōu)化前后的效果。這里提供了一種手段去做前后對比。可能這個方式不是太科學(xué)的，但是畢竟提供一種可量化的手段。
各業(yè)務(wù)系統(tǒng)差異較大，沒有必要做橫向?qū)Ρ?。A系統(tǒng)60分，B系統(tǒng)50分，不代表A的質(zhì)量就比B的質(zhì)量高。
單一系統(tǒng)可多做縱向?qū)Ρ?，即對比改造?yōu)化前后的規(guī)則總分?？稍谝欢ǔ潭壬戏从吵鱿到y(tǒng)質(zhì)量的變化。
對象審核結(jié)果明細(xì)
這部分是對象審核的明細(xì)部分，對應(yīng)每個規(guī)則其詳細(xì)情況，可在左側(cè)鏈接中進(jìn)一步查看對象信息。篇幅所限，不做展示了。
執(zhí)行計劃審核結(jié)果概覽
這部分執(zhí)行計劃的概覽展示，跟對象的情況類似。也是每種規(guī)則的扣分情況。
執(zhí)行計劃審核結(jié)果明細(xì)
這部分是執(zhí)行計劃的明細(xì)部分。
展開之后，可以看到違反每種規(guī)則的明細(xì)。上圖就是違反全表掃描的規(guī)則的明細(xì)部分。
在上面是一些通用的解決方案說明。這里將可能觸發(fā)此類規(guī)則的情況及解決方案進(jìn)行了說明。相當(dāng)于一個小知識庫，便于開發(fā)人員優(yōu)化。后面在平臺二期，會做更為精準(zhǔn)的優(yōu)化引擎部分，這部分還會展開。
下面是每條違反的語句情況，我們可以看到語句文本、執(zhí)行計劃、關(guān)聯(lián)信息（例如此規(guī)則的大表名稱）等。還可以進(jìn)一步點開語句，展開信息。
這部分是針對每條SQL的信息，包括語句文本、執(zhí)行計劃、執(zhí)行特征、關(guān)聯(lián)對象統(tǒng)計信息等。DBA可從這些信息就可以做一些初步的優(yōu)化判斷工作。
此外，平臺也提供了導(dǎo)出功能?？蓪?dǎo)出為excel文件，供用戶下載查看。這里就展示了。
在實際開發(fā)過程中，碰到了很多問題。我們這里簡單介紹兩個，例如：
MySQL在解析json格式執(zhí)行計劃中暴露出的問題…
【會話進(jìn)入sleep狀態(tài)，假死】
解決方法：執(zhí)行會話之前設(shè)置wait_timtout=3,這個時間根據(jù)實際情況進(jìn)行調(diào)整。
【數(shù)據(jù)量過大，長時間沒有結(jié)果】
會話處于query狀態(tài)，但是數(shù)據(jù)量很大或因為數(shù)據(jù)庫對format=json支持不是很好，長時間解析不出來，會影響其他會話。
解決方法：使用pt-kill工具殺掉會話。為了防止誤殺，可打個標(biāo)識“eXplAin format=json”，然后使用pt-kill識別eXplAin關(guān)鍵字。
此平臺在宜信公司運行以來，為很多系統(tǒng)提供了審核報告，大大加快了數(shù)據(jù)庫結(jié)構(gòu)、SQL優(yōu)化的速度，減輕了DBA的日常工作壓力。在工作實施過程中，我們也摸索了一套推行方法。該平臺已開源后，如有朋友使用，可參考實施。
收集信息階段
海量收集公司的數(shù)據(jù)庫系統(tǒng)的運行情況，掌握第一手資料?？焖倭私飧鳂I(yè)務(wù)系統(tǒng)的質(zhì)量，做好試點選擇工作。
人工分析階段
重點系統(tǒng)，人工介入分析。根據(jù)規(guī)則審核中暴露出的核心問題，“以點帶面”，有針對性的給出分析及優(yōu)化報告。
交流培訓(xùn)階段
主動上門，跟開發(fā)團(tuán)隊溝通交流報告情況。借分析報告的機會，可對開發(fā)團(tuán)隊進(jìn)行必要的培訓(xùn)工作，結(jié)合他們身邊的案例，更具有說服作用。
反饋改進(jìn)階段
落實交流的成果，督促其改進(jìn)。通過審核平臺定期反饋改進(jìn)質(zhì)量。有一定基礎(chǔ)的團(tuán)隊，可開發(fā)平臺，供開發(fā)人員自己使用。使SQL質(zhì)量問題，不再僅僅是DBA的問題，而和項目中的每個人都有關(guān)系。
內(nèi)容來源：宜信技術(shù)學(xué)院
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
重慶分公司
重慶分公司
