506
性能優化利器：數據庫審核平台的選型與實踐（附PPT）
今天我將從三個方麵進行分享：首先我們看一下為什麼我們想要開發這個平台，最初我們想做一個什麼樣的選型，怎麼樣來設計的，後麵會講一下平台實現過程，包括實現的一些基本原理、方法和一些功能介紹，最後會談一下平台不足的地方，以及未來的發展。
目前這個項目已開源，歡迎大家參與到這個項目裏麵去，不斷地完善它，發展它。
一、麵臨的挑戰
1、運維規模及種類
我相信，這也是很多公司、很多DBA正在麵臨或未來都會麵臨的一些問題。正是存在問題，促使我們考慮引入數據庫審核平台。
首先是運維規模與人力資源之間的矛盾。從我們的情況來看，運維了包括Oracle、MySQL、MongoDB、Redis四類數據庫，數據庫規模幾十套，支持公司千餘名開發人員及上百套業務係統。也許有的朋友會問，從運維規模上看，並不是很大。
的確，與很多互聯網公司相比，數據庫數十套的估摸並不是太大；但與互聯網類公司不同，類似宜信這類金融類公司對數據庫的依賴性更大，大量的應用是重數據庫類的，且其使用複雜程度也遠比互聯網類的複雜。DBA除了日常運維（這部分我們也在通過自研平台提升運維效率）外，還需要有大量精力應對數據庫設計、開發、優化類的工作。當麵對大量的開發團隊需要服務時，這個矛盾就更加凸顯出來。
2、案例
-
結構設計
第二個挑戰，是數據庫設計、開發質量參差不齊的問題。這頁就展示了一個結構設計問題。某核心係統的核心表，在這個係統運行的SQL中，28%都是跟這個對象有關的。當我們分析其結構時，發現了很多的問題：
-
表的規模很大，從設計之初就沒有考慮到拆分邏輯（例如分庫、分表、分區設計），也沒有必要的數據庫清理、歸檔策略。
-
表存在100多個字段，字段數很多且不同字段使用特征也不一致，沒有考慮到必要拆表設計。
-
表有13個索引，數目過多。表的索引過度，勢必會影響其DML效率。
-
還存在一個索引，在持續監控中發現，其從未被使用過。顯然這是一個“多餘”的索引。
-
還有兩個字段存在重複索引的現象，這也說明在建立索引之初是比較隨意的。
-
單個記錄定義長度為5800多個字節，但實際其平均保存長度隻有不到400字節，最大長度也不長。
-
分析其字段內容，還發現有3個字段類型定義異常。即沒有使用應有的類型保存數據，例如使用數字類型保存日期。
綜上所述，這個表設計的問題還有很多，而且這個表非常重要，大量語句訪問和其相關。
-
SQL語句
這頁展示的是一個語句運行效率的問題。從字麵可見，兩個表做關聯查詢，但在指定條件時沒有指定關聯條件。在下麵的執行計劃中可見，數據庫采用了笛卡爾積的方式運行。從後麵的成本、估算時間等可見，這是一個多麼“巨大”的SQL。其在線上運行的影響，可想而知。
也許有的朋友會說，這是一個人為失誤，一般不會發生。但我要說的是，第一，人為失誤無法避免，誰也不能保證寫出SQL的運行質量；第二，開發人員對數據庫的理解不同，很難保證寫出的SQL都是高效的；第三，開發人員麵臨大量業務需求，經常處理趕工狀態，很難有更多的精力放在優化上麵。這因為有這些問題，線上語句執行質量就成了DBA經常麵臨的挑戰之一。
3、重心轉移
這是一張很經典的圖，它描述了和數據庫相關工作的職能劃分。作為DBA，除了麵臨以上挑戰外，從數據庫工作發展階段及自身發展需求來看，也麵臨一個重心的轉移：原有傳統DBA的運維職能逐步被弱化，大量的工具、平台的湧現及數據庫自我運維能力的提升，簡化DBA的工作；緊隨而來的數據庫架構、結構設計、SQL質量優化逐步成為重點；再往上層的數據治理、建模等工作也越來越受到一些公司的重視。由此可見，DBA未來工作的中心也逐步上移。對中間數據邏輯結構部分，也需要一些工具、平台更好地支撐DBA的工作。
除上述情況外，我司還存在幾種的不平衡。
-
從DBA日常工作來看，傳統運維工作還是占了較大的比重，而架構優化類則相對較少。通過引入這一平台，可以幫助DBA更方便地開展架構、優化類工作。
-
公司使用了較多的商業產品，而開源則使用較少。從公司長遠戰略來看，開源產品的使用會越來越多。從功能角度來看，商業產品相較於開源產品是有優勢的。基於開源產品的軟件開發，對開發者自身技術技能要求更高。希望通過引入這一產品，可以更容易完成這一轉型過程。
-
沒有平台之前，DBA還是大量通過手工方式設計、優化數據庫，其效率十分低下。特別是麵對眾多產品線、眾多開發團隊時，往往感覺力不從心。
-
公司自有團隊人員上，還是以初中級為主，中高級人員相對較少。如何快速提升整體設計、優化能力，保證統一的優化效果成為擺在麵前的問題。
正是有了上述多種的不平衡，促使我們考慮引入工具、平台去解決數據庫質量問題。
我剛來到公司時，看到公司的這些問題，也曾考慮通過製度、規範的形式進行解決。一開始就著手製定了很多的規範，然後在各個部門去培訓、宣講。這種方式運行一段時間後，暴露出一些問題：
-
整體效果改善並不明顯。實施效果取決於各個部門的重視程度及員工的個人能力。
-
規範落地效果無法度量，也很難做到量化分析。往往隻能通過上線運行結果來直觀感知。
-
缺乏長期有效的跟蹤機製。無法對具體某個係統長期跟蹤其運行質量。
-
從DBA的角度來看，麵對大量的係統，很難依據每個規範，詳細審核其結構設計、SQL運行質量。
麵臨上述這些挑戰、現存的各種問題，該如何解決？
經過討論，最後大家一致認為，引入數據庫審核平台，可以幫助解決上麵所述問題。
二、平台的選型
1、業內做法
在項目之初，我考察了業內其它企業是如何數據庫審核的，大致可分為三個思路：
第一類，是以BAT公司為代表的互聯網類公司。它們通過自研的SQL引擎，可實現成本分析、自動審核、訪問分流、限流等，可做到事前審核、自動審核。但技術難度較大，公司現有技術能力明顯不足。
第二類，是通過自研工具收集DB運行情況，根據事前定義規則進行審核，結合人工操作來完成整個審核流程。這種方案隻能做到事後審核，但技術難度較小，靈活度很大。其核心就是規則集的製定，可根據情況靈活擴展。
第三類，是一些商業產品，實現思路類似第二類，但是加上一些自主分析能力，功能更為強大，但仍需人工介入處理且需要不小資金投入。而且考察幾款商業產品，沒有能完全滿足所需功能的。
綜合上麵幾類做法，最終確定我們采用“工具+人工審核”的方式，自研自己的審核平台。
2、我們的選擇——自研
在啟動研發這一平台之初，我們就在團隊內部達成了一些共識。
-
DBA需要扭轉傳統運維的思想，每個人都參與到平台開發過程中。
-
過去我們積累的一些內容（例如前期製定的規範）可以作為知識庫沉澱下來，並標準化，這些為後期規則的製定做好了鋪墊。
-
在平台推進中，從最簡單的部分入手，開發好的就上線實施，觀察效果；根據實施效果，不斷修正後麵的工作。
-
結合我們自身的特點，定製目標；對於有些較複雜的部分，可果斷延後甚至放棄。
-
參考其它公司或商業產品的設計思想，大膽引入。
三、審核平台實踐
下麵來看看，審核平台的基本功能及實現原理及方法，這部分是本次分享的重點。
1、平台定位
在項目之初，我們就平台的定位做了描述：
-
平台的核心能力是快速發現數據庫設計、SQL質量問題。
-
平台隻做事後審核，自主優化部分放在二期實現。當然在項目設計階段引入這個，也可以起到一部分事前審核的功能。
-
通過Web界麵完成全部工作，主要使用者是DBA和有一定數據庫基礎的研發人員。
-
可針對某個用戶審核，可審核包括數據結構、SQL文本、SQL執行特征、SQL執行計劃等多個維度。
-
審核結果通過Web頁麵或導出文件的形式提供。
-
平台需支持公司主流的Oracle、MySQL，其它數據庫放在二期實現。
-
盡量提供靈活定製的能力，便於日後擴展功能。
2、平台使用者
作為平台的兩類主要使用方，研發人員和DBA都可以從平台中受益。
-
對於研發人員而言，隻用這平台可方便定位問題，及時進行修改；此外通過對規則的掌握，也可以指導他們設計開發工作。
-
對於DBA而言，可快速掌握多個係統的整體情況，批量篩選出低效SQL，並可通過平台提供的信息快速診斷一般性問題。
3、實現原理
整個平台的基本實現原理很簡單，就是將我們的審核對象（目前支持四種），通過規則集進行篩選。符合規則的審核對象，都是疑似有問題的。平台會將這些問題及關聯信息提供出來，供人工甄別使用。由此可見，平台的功能強大與否，主要取決於規則集的豐富程度。平台也提供了部分擴展能力，方便擴展規則集。
4、平台設計
-
審核對象
在開始介紹平台實現之前，再來熟悉下“審核對象”這個概念。目前我們支持的有四類對象，分別說明一下。
-
對象級。這裏所說的對象就是指數據庫對象，常見的表、分區、索引、視圖、觸發器等等。典型規則，例如大表未分區等。
-
語句級。這裏所說的語句級，實際是指SQL語句文本本身。典型規則，例如多表關聯。
-
執行計劃級。這裏是指數據庫中SQL的執行計劃。典型規則，例如大表全表掃描。
-
執行特征級。這裏是指語句在數據庫上的真實執行情況。典型規則，例如掃描塊數與返回記錄比例過低。
需要說明一下，這四類審核對象中，後三種必須在係統上線運行後才會抓取到，第一種可以在隻有數據結構的情況下運行(個別規則還需要有數據)。
此外，上述規則中，除了第二類為通用規則外，其他都與具體數據庫相關。即每種的數據庫，都有自己不同的規則。
-
架構簡圖
這裏畫出是係統架構框架簡圖，我簡單說明一下。
圖中的方框部分，為平台的主要模塊。底色不同的模塊，表示當前的進度狀態不同。虛線代表數據流，實線代表控製流。其核心為這幾個模塊：
-
數據采集模塊。它是負責從數據源抓取審核需要的基礎數據。目前支持從Oracle、MySQL抓取。
-
OBJ/SQL存儲庫。這是係統的共同存儲部分，采集的數據和處理過程中的中間數據、結果數據都保存在這裏。其核心數據分為對象類和SQL類。物理是采用的MongoDB。
-
核心管理模塊。圖中右側虛線部分包含的兩個模塊：SQL管理和OBJ管理就是這部分。它主要是完成對象的全生命周期管理。目前隻做了簡單的對象過濾功能，因此還是白色底色，核心的功能尚未完成。
-
審核規則和審核引擎模塊。這部分是平台一期的核心組件。審核規則模塊是完成規則的定義、配置工作。審核引擎模塊是完成具體規則的審核執行部分。
-
優化規則和優化引擎模塊。這部分是平台二期的核心組件。目前尚未開發，因此為白色底色。
-
係統管理模塊。這部分是完成平台基礎功能，例如任務調度、空間管理、審核報告生成、導出等功能。
-
流程圖
讓我們從處理流程的角度，看看平台的整體處理過程。
-
“規則管理”部分，這部分主要完成以下一些功能。
-
初始化規則。平台本身內置了很多規則，在這一過程中到導入到配置庫中。
-
新增規則。平台本身提供了一定的擴展能力，可以依據規範新增一條規則。
-
修改規則。可以根據自身情況開啟或關閉規則。對於每條規則，還內置了一些參數，也可在此處修改。此外，針對違反規則的情況，還可以設置扣分方法（例如違反一次扣幾分、最多可扣幾分）等。
* 規則本身及相關參數、配置信息等都會存儲在配置庫中。
2.“任務管理”部分，這是後台管理的一個部分，主要完成與任務相關的工作。係統中的大多數交互都是通過作業異步完成的。其後台是通過celery+flower實現的。
3.“數據采集”部分，這部分是通過任務調度定時出發采集作業完成，也有少量部分是實時查詢線上庫完成的。采集的結果保存在數據庫中，供後續分析部分調用。
4.“規則解析”部分，這部分是由用戶通過界麵觸發，任務調度模塊會啟動一個後台異步任務完成解析工作。之所以設計為異步完成，主要是審核工作可能時間較長（特別是選擇審核類別較多、審核對象很多、開啟的審核規則較多）的情況。審核結果會保存在數據庫中。
5.“任務查看、導出”部分，在用戶發起審核任務後，可在此部分查看進度（處於審核中、還是審核完成）。當審核完成後，可選擇審核任務，瀏覽審核結果或選擇導出均可。如果是選擇導出的話，會生成異步後台作業生成文件，放置在下載服務器上。
以上就是整個審核的大體流程。後續將看到各部分的詳細信息。
-
模塊劃分
總結一下，平台主要是由上述四個模塊組成：數據采集、規則解析、係統管理、結果展示。後麵將針對不同模塊的實現，進行詳細說明。
5、數據采集
-
采集內容
先來看看數據采集模塊。從表格可見，兩種類型數據庫的采集內容不同。
Oracle提供了較為豐富的信息，需要的基本都可采集到；MySQL功能相對能采集到的信息較少。
表格中的“對號+星號”，表示非定時作業完成，而是後麵實時回庫抓取的。下麵簡單說下，各部分的采集內容。
-
對象級，采集了對象統計信息、存儲特征、結構信息、訪問特征。
-
SQL級，采集了SQL文本，執行計劃、緩存遊標、綁定變量、執行特征等。
這些信息都將作為後麵審核的依據。
-
采集原理
下麵簡單介紹下采集的與原理：
Oracle部分，是通過定時作業采集的AWR數據，然後轉儲到一套MongoDB中。這裏跟有些類似產品不同，沒有直接采集內存中的數據，而是取自離線的數據。其目的是盡量減少對線上運行的影響。Oracle提供的功能比較豐富，通過對AWR及數據字典的訪問，基本就可以獲得全部的數據。
MySQL部分，情況就要複雜一些，原因是其功能沒有那麼豐富。多類數據是通過不同源來獲取。SQL文本類及執行特征類的，是通過pt工具分析慢查詢日誌定時入到Anemometer平台庫，然後從此庫傳入MongoDB。其它類信息（包括數據字典類、執行計劃類等）是在需要時通過實時回庫查詢的。為了防止影響主庫，一般是通過路由到從庫上執行獲得的。
6、規則解析
-
概要說明
下麵介紹整個係統最為核心的部分—規則解析模塊，它所完成的功能是依據定義規則，審核采集的數據，篩選出違反規則的數據。對篩選出的數據進行計分，並記錄下來供後續生成審核報告使用。同時還會記錄附加信息，用於輔助進行一些判斷工作。
這裏有個核心的概念—“規則”。後麵可以看到一個內置規則的定義，大家就會比較清楚了。從分類來看，可大致分為以下幾種。
-
從數據庫類型角度來區分，規則可分為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的查詢語句。後麵我們會可看到一個詳細的示例。
7、平台實現
-
規則實現
這裏以“大表全表掃描”規則為例，進行說明。上麵是在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，是通過程序判斷括號嵌套來完成對子查詢(或多級子查詢)的判斷。
-
規則定義（執行特征級）
最後一類規則是執行特征類的。這部分是與數據庫緊密關聯的，將符合一定執行特征的語句篩選出來。這些語句不一定是低效的，可能隻是未來考慮優化的重點，或者說優化效益最高的一些語句。這裏麵主要都是一些對資源的消耗情況等。
8、係統管理
-
規則管理
後麵通過一些界麵展示，介紹下平台的功能。
第一部分係統管理模塊中規則管理的部分。在這部分，可完成新增自有規則。其核心是規則實現部分，通過SQL語句、Mongo查詢語句、自定義Python文件的形式定義規則實現體。自定義規則的依據是現有抓取的數據源，定義者需要熟悉現有數據結構及含義。目前尚不支持自定義抓取數據源。
對定義好的規則，可在此處完成規則修改。主要是對規則狀態、閥值、扣分項等進行配置。
-
任務管理
在配置好規則後，可在此處完成任務發布的工作。
上麵是規則任務發布的界麵，在選擇數據源(ip、port、schema)後，選擇審核類型及審核日期。目前審核數據源的定時策略還是以天為單位，因此日期不能選擇當天。
當任務發布後，可在任務結果查看界麵觀察執行情況。根據審核類型、數據源對象多少、語句多少等，審核的時長不定，一般是在5分鍾以內。當審核作業狀態為“成功”時，代表審核作業完成，可以查看或導出審核結果了。
9、結果展示
-
對象審核結果概覽
上圖是一個對象審核報告的示例。在報告的開頭部分，是一個概覽頁麵。它集中展示審核報告中各類規則及扣分情況；並通過一個餅圖展示其占比情況。這便於我們集中精力先處理核心問題。
在最上麵，還可以觀察到有一個規則總分的顯示。這是我們將規則扣分按照百分製，折算後得到的一個分數。分值越高，代表違反的情況越少，審核對象的質量越高。引入“規則總分”這一項，在設計之初是有些爭議的，擔心有了這個指標會比較打擊開發人員的積極性，不利於平台的推廣使用。這裏有幾點，我說明一下。
-
引入規則總分，是為了數據化數據庫設計、開發、運行質量。以往在很多優化中，很難去量化優化前後的效果。這裏提供了一種手段去做前後對比。可能這個方式不是太科學的，但是畢竟提供一種可量化的手段。
-
各業務係統差異較大，沒有必要做橫向對比。A係統60分，B係統50分，不代表A的質量就比B的質量高。
-
單一係統可多做縱向對比，即對比改造優化前後的規則總分。可在一定程度上反映出係統質量的變化。
-
規則總分，跟規則配置關係很大。如關閉規則或將違反規則的閥值調低，都會提高分數。這要根據係統自身情況來確定。同一規則，對不同係統使用，其閥值是可以不同的。舉例而言，數據倉庫類的應用，大表全部掃描就是一個比較正常的行為，可考慮關閉此規則或將單次違反閥值、總扣分上限降低。
-
對象審核結果明細
這部分是對象審核的明細部分，對應每個規則其詳細情況，可在左側鏈接中進一步查看對象信息。篇幅所限，不做展示了。
-
執行計劃審核結果概覽
這部分執行計劃的概覽展示，跟對象的情況類似。也是每種規則的扣分情況。
-
執行計劃審核結果明細
這部分是執行計劃的明細部分。
展開之後，可以看到違反每種規則的明細。上圖就是違反全表掃描的規則的明細部分。
在上麵是一些通用的解決方案說明。這裏將可能觸發此類規則的情況及解決方案進行了說明。相當於一個小知識庫，便於開發人員優化。後麵在平台二期，會做更為精準的優化引擎部分，這部分還會展開。
下麵是每條違反的語句情況，我們可以看到語句文本、執行計劃、關聯信息（例如此規則的大表名稱）等。還可以進一步點開語句，展開信息。
這部分是針對每條SQL的信息，包括語句文本、執行計劃、執行特征、關聯對象統計信息等。DBA可從這些信息就可以做一些初步的優化判斷工作。
此外，平台也提供了導出功能。可導出為excel文件，供用戶下載查看。這裏就展示了。
10、我們遇到的坑
在實際開發過程中，碰到了很多問題。我們這裏簡單介紹兩個，例如：
MySQL在解析json格式執行計劃中暴露出的問題…
【會話進入sleep狀態，假死】
解決方法：執行會話之前設置wait_timtout=3,這個時間根據實際情況進行調整。
【數據量過大，長時間沒有結果】
會話處於query狀態，但是數據量很大或因為數據庫對format=json支持不是很好，長時間解析不出來，會影響其他會話。
解決方法：使用pt-kill工具殺掉會話。為了防止誤殺，可打個標識“eXplAin format=json”，然後使用pt-kill識別eXplAin關鍵字。
11、推進流程
此平台在宜信公司已運行了半年有餘，為很多係統提供了審核報告，大大加快了數據庫結構、SQL優化的速度，減輕了DBA的日常工作壓力。在工作實施過程中，我們也摸索了一套推行方法。後續平台開源後，如有朋友使用，也可參考實施。
-
收集信息階段
海量收集公司的數據庫係統的運行情況，掌握第一手資料。快速了解各業務係統的質量，做好試點選擇工作。
-
人工分析階段
重點係統，人工介入分析。根據規則審核中暴露出的核心問題，“以點帶麵”，有針對性的給出分析及優化報告。
-
交流培訓階段
主動上門，跟開發團隊溝通交流報告情況。借分析報告的機會，可對開發團隊進行必要的培訓工作，結合他們身邊的案例，更具有說服作用。
-
反饋改進階段
落實交流的成果，督促其改進。通過審核平台定期反饋改進質量。有一定基礎的團隊，可開發平台，供開發人員自己使用。使SQL質量問題，不再僅僅是DBA的問題，而和項目中的每個人都有關係。
Q&A
Q1：您剛才說的把規則，字段類型不匹配，得到一個規則以後反饋過來，怎麼就知道它必須是那個類型呢？
A1：我們首先會從數據表裏麵分析你這個字段裏麵想保存什麼數據，比如說你這裏麵存的都是0到9，我就會分析這裏麵是不是應該保存一個數字，你拿文本存的，我就考慮為什麼，我在排除了不是郵編，不是手機號，不是銀行帳號各種排除之後，我覺得還不符合，那我就要考慮你定義它的初衷是什麼。我認為你這個類型存的，但你實際上按另外一個類型存的，我就要考慮為什麼這樣做的，我可能就會扣一個分。
所謂類型不匹配是由於我們之前的功能引出來的，因為我們是金融公司，有很多數據是有敏感信息的，所以我們開始做了一個敏感信息的識別，我們會自動看你這個字段是不是敏感字段，進而我們發現可以拿一些數據特征的，演變過來就變成這個規則，就是所謂字段類型不匹配，當然這個可能會有一定的誤判，有人認為文本類型，比如說數字類型效率差不多，我認為合理也OK，隻要你給自己一個理由。
我有時候會把研發人員叫過來說你，這麼設計可以，但你要給我一個理由。我不希望看到除了第一個字段以外，剩下所有字段都是一個長度的，這個就不太合理。我們希望這個維度可以反映出來一些問題。
Q2：意思就是通過一定的算法？
A2：沒有什麼算法，表多大，10兆以下的，我們會根據不同大小拆成片，比如說這個表是多大表我們就多拆幾片，每一片裏麵會根據閥值來做，我們會得到一個匯總的結果集，我們會評估你的這些數據是什麼樣的，在排除那些特例情況之後，我認為它是不是違反規則，沒有什麼算法，其實就是一個政策匹配，我們目前線上基本上每一片采一千個數據。
Q3：我剛才聽到老師的演講裏麵，就是說讓一些技術人員跟一些業務部門或者別部門進行溝通和交流，我自己學數據庫的時候，我前後總共有4個老師，我對4個老師講的數據庫不是特別感興趣，實際工作當中，我發現在談公司決策的時候沒有數據參考的，甚至國內或者國際谘詢公司也缺失了很多數據，我從個人和企業訴求來說，有一部分數據是理性的，還有一部分數據在網絡公司很分散的，這樣的局麵下，它的用戶量很大，怎麼把數據進行統一的匯總起來？或者通過手機端讓客戶得到想要的數據，這個跟宜信之間也有直接關聯，發公司有月頭月底，這個之間也是產生關聯的，也就是說我們現在在做決策的時候，有一部分數據是沒有的，沒有數據的情況下還要做決策，這樣的數據架構怎麼來做？
剛才聽就了這麼一個重點，就是我們現在做決策的時候有一些數據是沒有的，這個情況下在數據庫裏麵應該怎麼設計？或者跟他做一個運營。
A3：坦白說，我沒太聽懂你的問題，我理解你的意思是說如果公司缺乏一些數據支撐的情況下，怎麼樣做業務的決策是嗎？
（接上問）
Q4：中國的企業很多決策是老板拍腦袋。
A4：還有一個問題就是技術人員怎麼和業務人員溝通。
我們原來公司DBA確實大家都在幕後做工作，跟前台業務開發聯係也不多，出了問題大家一起看，2016年初我們小夥伴們提了一些建議，我們在企業裏麵要發揮你的價值，作為傳統運維來說，你的價值是你的數據庫是可外的，除此之外要和研發人員有更好的一些互動。我現在要求這些人員要跟項目在一起，要跟它的產品聊，跟研發人員聊，這樣才能更好的理解這些項目，理解這些業務，進而才有可能幫助他們做一些輔助設計。
最簡單的，這個存什麼樣的數據，這個數據怎麼使用的，保存有什麼樣的特征，我們目標用戶是什麼樣的，這些東西你是需要了解的，隻有這樣前提下我們才有可能把工作做到前麵去，我們做一些數據庫的架構設計、結構設計，這樣的語句合理還是不合理，這個時候才有可能做這個事。這個就要求項目同事，我說你們要主動推出去，而不是坐在後麵，說這個出問題了我看一眼，我們看過這種事情，優化了一個月，最後我說了兩句之後個東可以砍掉的，他的目的是解決這個問題，你要充分了理解它的訴求之後，你幫助他解決問題，這個問題可能是數據庫的結構調整，可能是一個優化，也有可能其他方麵解決問題，比如說這個功能可以更好實現。有的業務我就告訴他，這個東西放在數據庫裏運行不合適的，我可以你更好的方式實現它，成本更低，效率更好。
至於你說的第一個問題，如果說一個公司沒有數據支撐的話，怎麼樣做業務決策，這個我也不知道。我隻能說比如說我們公司現在的運營數據會通過自有的平台，這個平台之前在社區做過一些分享，把這個數據實時的抽過來，基於我們規則做一些分析。通過它做一些運營知識，當然宜信這方麵做的並不是太突出，隻是剛剛起步做一些這方麵的嚐試。
更多的可能像您說的會有一些認為決策的過程，當然我希望後麵通過像我，包括我們同事，包括我們所有的不一定數據庫團隊，而是數據團隊幫助公司更好做整體業務模型，數據類的一些架構，幫助彌補看我們公司哪一些數據領域沒有這些數據支撐的，把它的短板需要補充，當然這個需要從更高層麵看一些問題。
Q5：請問韓老師從研究、規劃到落地，用了多長時間，幾個人天，難在什麼地方。有沒有結合SQL語句對係統開銷的貢獻選擇top，還是一視同仁？
A5：程序開發是由一名專職開發+兩名DBA，在日常工作之外，用了大概半年左右完成的。難點，主要是個別規則實現，整體還好。在執行特征審核中，會考慮對係統開銷的影響
最後更新：2017-05-16 10:32:30