關(guān)鍵詞： sql審核、sql審批、sql檢查、sql檢測、sql執(zhí)行
離線sql可能會導(dǎo)致的問題
首先，什么是離線sql呢？就是說手動觸發(fā)執(zhí)行的這種sql；相對的還有在線sql，位于我們的程序代碼中，由程序觸發(fā)執(zhí)行的sql是在線sql。舉個例子，我們想要建庫、建表、改表的時候，通常會編寫sql語句，選一個合適的時間執(zhí)行；這就是離線SQL。當(dāng)然，操作數(shù)據(jù)的離線sql也是有的，比方說線上程序bug，我們想要手動修復(fù)個別數(shù)據(jù)，這時候也會提交離線的修改數(shù)據(jù)的SQL。
那么，離線的sql可能會導(dǎo)致哪些問題呢？這個說起來還挺多的，我們來列舉一下。建表或者改表的時候，可能會存在不規(guī)范的列，比如我們可能會不希望字段存在空值；可能會不小心使用不同的字符集；可能會不小心創(chuàng)建了重復(fù)的索引，給變更數(shù)據(jù)帶來不必要的負擔(dān)。而操作數(shù)據(jù)的時候，如果數(shù)據(jù)量特別大，一個不走索引的查詢或者變更語句就可能給db帶來災(zāi)難；或者偶爾由于手速過快，提交了不帶條件限制的變更語句；另外，手動操作難免偶爾出錯，出錯了再去糾正數(shù)據(jù)也會十分麻煩。
如何避免問題
如何避免這些問題呢？最簡單的方式是我們每次執(zhí)行sql都提交給dba，由dba同學(xué)手動檢查后執(zhí)行。如果公司規(guī)模很小，這樣的話還能湊合（如果公司有dba同學(xué)的話），但人工審核也難免有注意不到的地方；而公司規(guī)模比較大的話，就比較費dba同學(xué)了【手動狗頭】。
那我們可以在這個基礎(chǔ)上再加一層：由研發(fā)leader審核完后，再由dba同學(xué)審核并執(zhí)行。這樣可以減輕dba同學(xué)的工作量，但是還是沒有辦法避免人工檢查的遺漏。而且也沒有辦法方便的進行數(shù)據(jù)備份。
那么有沒有更好的方式呢？當(dāng)然是有的，把檢查sql的標(biāo)準(zhǔn)梳理清楚形成一條一條的規(guī)則，然后固化到程序里，由程序來應(yīng)用規(guī)則完成首輪檢查，并在執(zhí)行的時候，進行數(shù)據(jù)備份，需要時還可以進行數(shù)據(jù)回滾。
現(xiàn)成可使用的工具-Owl
Owl就是這樣一個開源工具，它提供sql提交流程審批、按規(guī)則檢測sql、執(zhí)行sql、備份、回滾等功能，可以用以管理起來所有的離線sql執(zhí)行場景。它讓我們的db數(shù)據(jù)更規(guī)范、db集群更安全。下圖是它的一個流程結(jié)構(gòu)示意圖。
首先它提供一個審批流程的地方，研發(fā)同學(xué)想要對自己訪問不到（網(wǎng)絡(luò)隔離）的線上環(huán)境執(zhí)行sql時，可以在Owl上提交sql執(zhí)行的請求工單，分別經(jīng)過規(guī)則審核、leader審核、dba審核后，由dba在Owl上直接執(zhí)行。
規(guī)則審批即是通過一些規(guī)則限制可執(zhí)行的sql。這些規(guī)則的實現(xiàn)還是挺有意思的，感興趣的同學(xué)可以去代碼中看，文末會有地址。規(guī)則舉例：1，表必須使用utf8字符集；2，列和表都必須要有注釋；3，變更數(shù)據(jù)影響行數(shù)不能超過100；4，變更數(shù)據(jù)的sql必須完全匹配索引。上面這些都是具體的規(guī)則，規(guī)則可以打開或者關(guān)閉，打開狀態(tài)的規(guī)則會拒絕不滿足此條規(guī)則的sql。下圖是具體支持的部分規(guī)則截圖，目前已實現(xiàn)37條規(guī)則。
dba審核通過后，可以選擇定時執(zhí)行或者馬上執(zhí)行，如果是操作數(shù)據(jù)的sql，則執(zhí)行的時候會進行數(shù)據(jù)備份。之后，如果有需要可以進行數(shù)據(jù)回滾，回滾的時候會展示變更了哪些列以及原來的數(shù)據(jù)內(nèi)容。下圖是回滾時的截圖,所修改行的數(shù)據(jù)會展示為紅色。
當(dāng)然，為了可以使用上述的一些功能還需要一些基礎(chǔ)的功能模塊，比如用戶、管理員管理，集群管理、登陸認(rèn)證等。由于一些規(guī)則需要獲取具體的表數(shù)據(jù)信息來實現(xiàn)驗證，所以需要db的賬號和密碼。密碼是加密存儲在數(shù)據(jù)庫的，必須要有配置文件中的key和程序中固定的key才能解密，所以安全性是有保障的。
最后還需要說明的是：大批量的數(shù)據(jù)更新不適合通過owl去做，除非我們不需要做數(shù)據(jù)備份。因為owl的數(shù)據(jù)備份方式是特殊編碼后轉(zhuǎn)儲到一張db表里，數(shù)據(jù)量過大會給內(nèi)存帶來很大的壓力，也不適合放到表里了。
未來規(guī)劃
首先是分庫分表工具（gh-ost）的支持，有的公司使用了分庫分表的模式，Owl如果可以配置化的支持這個工具，用起來會更方便一些。
其次是支持?jǐn)?shù)據(jù)查詢功能，并使用部分規(guī)則加以限制，這是一個很常見的需求，沒什么好說的。
另外還想改造一下用戶相關(guān)的邏輯，讓沒有使用ldap做用戶管理的公司也能方便的用起來。讓使用更簡單是一個長期目標(biāo)。
以上的規(guī)劃會在半年內(nèi)逐步完成。
長遠來看還可以加入redis、es等其他存儲的讀寫功能，但是這個就比較久遠了。
求個star
最后，求一個star呀，每一個star都是對開源項目研發(fā)者的巨大鼓勵！
