背景

隨著伴魚業(yè)務的快速發(fā)展，公司各產品線的業(yè)務不斷豐富，日常的 SQL 上線也在不斷增加。SQL 審核與執(zhí)行，作為 DBA 每天工作中相當重要的一環(huán)，如何保證 SQL 語句的質量，對于系統(tǒng)的高效運行和長久穩(wěn)定有著很大的影響。

本文在對開源 SQL 審核平臺 (例如 Yearning、See 和 Archery 等) 進行調研，并結合 DBA 在 SQL 上線實踐經驗的基礎上，設計了伴魚 SQL 審核平臺。相比其它 SQL 審核平臺，新系統(tǒng)主要包括以下核心功能：

• 基于 TiDB Parse 做 SQL 語法解析，踐行 SQL 規(guī)范

• 基于公司組織架構做權限管理和流程審核

• 基于審核規(guī)則列表的動態(tài)開關

• 支持 SQL 執(zhí)行數據備份和回滾

• 支持任務定時調度執(zhí)行

下面從整體架構、流程設計等方面詳細介紹下伴魚 SQL 審核平臺以及設計背后的一些思考。

整體架構

SQL 審核架構，如下圖所示，主要包括 web 前端、 SQL 審核后端和數據存儲 TiDB。

流程設計

SQL 語句的質量對于系統(tǒng)的穩(wěn)定高效運行有很大影響，因此 SQL 審核平臺必須加強語句質量的審核。其次， SQL 審核平臺在確保數據庫平穩(wěn)運行的同時，盡量提高上線的效率。

規(guī)則設計

通過系統(tǒng)約束是踐行數據庫規(guī)范最有效的手段。SQL 審核規(guī)則除了加入業(yè)界認可的規(guī)則外，我們還根據日常 SQL 上線暴露的一些風險場景，加入我們設計的一些規(guī)則。SQL 審核部分規(guī)則列表，如下圖所示。

數據的刪改關系到數據安全和 SQL 性能，其中 SQL 性能關系到線上服務的穩(wěn)定性。這里簡單介紹下“刪改數據規(guī)則”，主要包括以下三條規(guī)則：

• 刪改數據索引不完全匹配

• 刪改數據影響行數超過 100

• 影響行數超過 3000

下面對這 3 條規(guī)則進行解釋：

• 日常數據修改，大多數場景只涉及少部分數據修改，所以只要完全走索引，性能基本沒問題。如果系統(tǒng)檢測到語句條件與線上索引不完全匹配，檢測結果就會不通過。

• 在某些特殊場景下，索引完全匹配，但數據影響的實際行數可能較多 (大于配置影響行數 100)，這樣檢測結果也是不通過。

• 當然在表數據量不大 (萬級別以內) 和索引沒法覆蓋等極少數場景下，可以通過關閉 1、2 兩條規(guī)則，同時滿足 3 這條規(guī)則的前提下，檢測通過。

規(guī)則這樣配置，一方面系統(tǒng)根據語句條件備份時，保證了快速高效；其次，數據執(zhí)行權限已經下放給業(yè)務負責人，系統(tǒng)盡可能保證 SQL 的執(zhí)行性能。

任務設計

業(yè)務 app 大版本上線，涉及 SQL 上線條數眾多，在任務設計上主要做了如下幾點考慮：

• 通常業(yè)務大版本上線，涉及多個業(yè)務線，所以 SQL 任務必須支持多庫多表

• SQL 任務通常包括建表、改表和增刪改數據三種類型，每種任務需要區(qū)別對待，比如建表不會鎖表，但需要關注表的索引；改表需要關注數據大小，任務最好不要在業(yè)務高峰期執(zhí)行；增刪改數據需要在執(zhí)行前對數據進行備份，保證數據安全。

基于以上兩點要求和任務提交的易用性，我們設計了任務檢測頁面，如下圖所示。

其中，對于建表選項，我們要求每個輸入框只輸入一條建表語句，并備注每個表的查詢和更新，這樣設計的原因是符合 DBA 審核習慣，方便 DBA 審核索引好壞。

任務檢測

研發(fā)提交 SQL 任務檢測后，后臺基于 SQL 審核規(guī)則，對語句進行語法和規(guī)則進行檢查，并將檢測結果反饋給研發(fā)。在任務檢測結果頁，從易用性角度做了如下幾點考慮：

• 提交檢測的 SQL 眾多，如果其中某些 SQL 不滿足要求，需要支持在檢測結果頁直接修改并立即檢測，不需要重新編輯所有任務再次提交

• 改表 (除加索引操作外) 只修改元數據，不需要拷貝數據，影響行數為 0，形象的“代表”執(zhí)行速度很快

• 刪改數據，我們需要將數據真正影響的行數展示給研發(fā)，讓他們看到實際操作的數據條數，形象的“告訴”數據操作是否符合目標

檢測結果頁，如下圖所示。

其中：

• 修改數據條件與索引不匹配，檢測狀態(tài)為失敗；

• 增加索引，需要拷貝全表數據，影響行數為表總條數；

• 增加字段和數據類型加大，只涉及修改元數據，影響行數為 0；

• 第 4 條更新語句，滿足刪改規(guī)則，檢測狀態(tài)通過；

• 整個任務單，有條語句未通過，只需要修改該條語句滿足審核規(guī)則，整個任務單才才可以提交審核，進入下一步流程。

任務審核

任務審核角色有 2 個，一級審核為業(yè)務負責人，負責審核任務提交同學的 SQL 質量，二級審核為 DBA ，進一步審核和提高 SQL 質量。審核流程，如下圖所示。

目前，任務審核流程如下：

• 對于增刪改數據操作，審核規(guī)則已經保證 SQL 性能和數據備份，審核和執(zhí)行權限下放給一級審核人

• 對于建表， DBA 關注表的索引好壞問題，審核和執(zhí)行權限由 DBA 負責

• 對于改表，涉及添加索引操作，需要關注語句的性能，審核和執(zhí)行權限由 DBA 負責

任務執(zhí)行

任務執(zhí)行階段，主要考慮 2 個問題，包括大表添加索引可能導致的性能問題和數據刪改可能導致的數據誤操作問題。針對這 2 個問題，我們采取的措施如下：

• 定時調度，大表加索引操作，可以設置調度時間，調度到業(yè)務低峰期執(zhí)行

• 數據備份，對于刪改數據操作，在真正執(zhí)行前，會根據語句條件，對數據進行備份

任務待執(zhí)行列表，如下圖所示。任務如果設置了定時調度，后臺調度到該設置的時間點執(zhí)行，當然待調度的任務也可以修改調度時間或者人工調度立即執(zhí)行。

任務歷史

任務歷史主要保存 SQL 語句操作記錄，便于審計。同時對于刪改操作，任務歷史提供數據回滾入口，如下圖所示。

總結及規(guī)劃

目前，伴魚 SQL 審核平臺簡化了 DBA 的工作，提高了研發(fā) SQL 上線效率和研發(fā)使用數據庫的水平。系統(tǒng)已穩(wěn)定運行近半年時間，審核規(guī)則也不斷完善，更加契合公司內部場景。未來，我們有以下幾點需要完善：

• 建表，目前小表采用自增主鍵，大表主鍵依賴公司分布式 id 生成器，后續(xù)版本升級到 4.0，小表主鍵可以使用 TiDB 自帶 auto_random 方式生成

• 建表，索引的好壞，還需要 DBA 人工平臺審核。在沒有有效的方式阻止引入性能較差的 SQL 到線上前，目前還不打算將執(zhí)行權限下放給業(yè)務負責人。后續(xù)將對這塊繼續(xù)進行研究，爭取做到自動化。

總結

以上是生活随笔為你收集整理的sql 修改时间戳语句_从 0 到 1 搭建技术中台之 SQL 审核平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。