摘要：正是存在問題，促使我們考慮引入數據庫審核平臺。的確，與很多互聯網公司相比，數據庫數十套的估摸并不是太大但與互聯網類公司不同，類似宜信這類金融類公司對數據庫的依賴性更大，大量的應用是重數據庫類的，且其使用復雜程度也遠比互聯網類的復雜。

作者：韓鋒 
出處：DBAplus社群分享 
Themis開源地址：https://github.com/CreditEaseDBA
拓展閱讀：宜信開源|數據庫審核軟件Themis的規則解析與部署攻略
【技術沙龍002期】數據中臺：宜信敏捷數據中臺建設實踐|宜信技術沙龍 將于5月23日晚8點線上直播，點擊報名

我相信，這也是很多公司、很多DBA正在面臨或未來都會面臨的一些問題。正是存在問題，促使我們考慮引入數據庫審核平臺。

首先是運維規模與人力資源之間的矛盾。從我們的情況來看，運維了包括Oracle、MySQL、MongoDB、Redis四類數據庫，數據庫規模幾十套，支持公司千余名開發人員及上百套業務系統。也許有的朋友會問，從運維規模上看，并不是很大。

的確，與很多互聯網公司相比，數據庫數十套的估摸并不是太大；但與互聯網類公司不同，類似宜信這類金融類公司對數據庫的依賴性更大，大量的應用是重數據庫類的，且其使用復雜程度也遠比互聯網類的復雜。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運行質量。

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

經過討論，最后大家一致認為，引入數據庫審核平臺，可以幫助解決上面所述問題。

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

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

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

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

綜合上面幾類做法，最終確定我們采用“工具+人工審核”的方式，自研自己的審核平臺。

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

DBA需要扭轉傳統運維的思想，每個人都參與到平臺開發過程中。

過去我們積累的一些內容（例如前期制定的規范）可以作為知識庫沉淀下來，并標準化，這些為后期規則的制定做好了鋪墊。

在平臺推進中，從最簡單的部分入手，開發好的就上線實施，觀察效果；根據實施效果，不斷修正后面的工作。

結合我們自身的特點，定制目標；對于有些較復雜的部分，可果斷延后甚至放棄。

參考其它公司或商業產品的設計思想，大膽引入。

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

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

平臺的核心能力是快速發現數據庫設計、SQL質量問題。

平臺只做事后審核，自主優化部分放在二期實現。當然在項目設計階段引入這個，也可以起到一部分事前審核的功能。

通過Web界面完成全部工作，主要使用者是DBA和有一定數據庫基礎的研發人員。

可針對某個用戶審核，可審核包括數據結構、SQL文本、SQL執行特征、SQL執行計劃等多個維度。

審核結果通過Web頁面或導出文件的形式提供。

平臺需支持公司主流的Oracle、MySQL，其它數據庫放在二期實現。

盡量提供靈活定制的能力，便于日后擴展功能。

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

對于研發人員而言，只用這平臺可方便定位問題，及時進行修改；此外通過對規則的掌握，也可以指導他們設計開發工作。

對于DBA而言，可快速掌握多個系統的整體情況，批量篩選出低效SQL，并可通過平臺提供的信息快速診斷一般性問題。

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

審核對象

在開始介紹平臺實現之前，再來熟悉下“審核對象”這個概念。目前我們支持的有四類對象，分別說明一下。

對象級。這里所說的對象就是指數據庫對象，常見的表、分區、索引、視圖、觸發器等等。典型規則，例如大表未分區等。

語句級。這里所說的語句級，實際是指SQL語句文本本身。典型規則，例如多表關聯。

執行計劃級。這里是指數據庫中SQL的執行計劃。典型規則，例如大表全表掃描。

執行特征級。這里是指語句在數據庫上的真實執行情況。典型規則，例如掃描塊數與返回記錄比例過低。

需要說明一下，這四類審核對象中，后三種必須在系統上線運行后才會抓取到，第一種可以在只有數據結構的情況下運行(個別規則還需要有數據)。

此外，上述規則中，除了第二類為通用規則外，其他都與具體數據庫相關。即每種的數據庫，都有自己不同的規則。

架構簡圖

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

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

數據采集模塊。它是負責從數據源抓取審核需要的基礎數據。目前支持從Oracle、MySQL抓取。

OBJ/SQL存儲庫。這是系統的共同存儲部分，采集的數據和處理過程中的中間數據、結果數據都保存在這里。其核心數據分為對象類和SQL類。物理是采用的MongoDB。

核心管理模塊。圖中右側虛線部分包含的兩個模塊：SQL管理和OBJ管理就是這部分。它主要是完成對象的全生命周期管理。目前只做了簡單的對象過濾功能，因此還是白色底色，核心的功能尚未完成。

審核規則和審核引擎模塊。這部分是平臺一期的核心組件。審核規則模塊是完成規則的定義、配置工作。審核引擎模塊是完成具體規則的審核執行部分。

優化規則和優化引擎模塊。這部分是平臺二期的核心組件。目前尚未開發，因此為白色底色。

系統管理模塊。這部分是完成平臺基礎功能，例如任務調度、空間管理、審核報告生成、導出等功能。

流程圖

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

1) “規則管理”部分，這部分主要完成以下一些功能。

初始化規則。平臺本身內置了很多規則，在這一過程中到導入到配置庫中。

新增規則。平臺本身提供了一定的擴展能力，可以依據規范新增一條規則。

修改規則。可以根據自身情況開啟或關閉規則。對于每條規則，還內置了一些參數，也可在此處修改。此外，針對違反規則的情況，還可以設置扣分方法（例如違反一次扣幾分、最多可扣幾分）等。

規則本身及相關參數、配置信息等都會存儲在配置庫中。

2) “任務管理”部分，這是后臺管理的一個部分，主要完成與任務相關的工作。系統中的大多數交互都是通過作業異步完成的。其后臺是通過celery+flower實現的。

3) “數據采集”部分，這部分是通過任務調度定時出發采集作業完成，也有少量部分是實時查詢線上庫完成的。采集的結果保存在數據庫中，供后續分析部分調用。

4) “規則解析”部分，這部分是由用戶通過界面觸發，任務調度模塊會啟動一個后臺異步任務完成解析工作。之所以設計為異步完成，主要是審核工作可能時間較長（特別是選擇審核類別較多、審核對象很多、開啟的審核規則較多）的情況。審核結果會保存在數據庫中。

5) “任務查看、導出”部分，在用戶發起審核任務后，可在此部分查看進度（處于審核中、還是審核完成）。當審核完成后，可選擇審核任務，瀏覽審核結果或選擇導出均可。如果是選擇導出的話，會生成異步后臺作業生成文件，放置在下載服務器上。

以上就是整個審核的大體流程。后續將看到各部分的詳細信息。

模塊劃分

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

采集內容

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

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文件，供用戶下載查看。這里就展示了。

在實際開發過程中，碰到了很多問題。我們這里簡單介紹兩個，例如：

MySQL在解析json格式執行計劃中暴露出的問題…

【會話進入sleep狀態，假死】

解決方法：執行會話之前設置wait_timtout=3,這個時間根據實際情況進行調整。

【數據量過大，長時間沒有結果】

會話處于query狀態，但是數據量很大或因為數據庫對format=json支持不是很好，長時間解析不出來，會影響其他會話。

解決方法：使用pt-kill工具殺掉會話。為了防止誤殺，可打個標識“eXplAin format=json”，然后使用pt-kill識別eXplAin關鍵字。

此平臺在宜信公司運行以來，為很多系統提供了審核報告，大大加快了數據庫結構、SQL優化的速度，減輕了DBA的日常工作壓力。在工作實施過程中，我們也摸索了一套推行方法。該平臺已開源后，如有朋友使用，可參考實施。

收集信息階段

海量收集公司的數據庫系統的運行情況，掌握第一手資料。快速了解各業務系統的質量，做好試點選擇工作。

人工分析階段

重點系統，人工介入分析。根據規則審核中暴露出的核心問題，“以點帶面”，有針對性的給出分析及優化報告。

交流培訓階段

主動上門，跟開發團隊溝通交流報告情況。借分析報告的機會，可對開發團隊進行必要的培訓工作，結合他們身邊的案例，更具有說服作用。

反饋改進階段

落實交流的成果，督促其改進。通過審核平臺定期反饋改進質量。有一定基礎的團隊，可開發平臺，供開發人員自己使用。使SQL質量問題，不再僅僅是DBA的問題，而和項目中的每個人都有關系。

內容來源：宜信技術學院