企業如何做好 SQL 質量管理?

研發人員寫 SQL 操作數據庫想必一定是一類基礎且常見的工作內容。如何避免 “問題” SQL 流轉到生產環境,保證數據質量?這值得被研發/DBA/運維所重視。

什麼是 SQL 問題?

對於研發人員來說,在日常工作中,大部分都需要使用數據庫。項目中的很多業務都需要進行增刪改查等常見數據庫操作,這些數據庫操作對應的 SQL 語句主要都是由開發人員編寫的。對於 DBA 來說,作爲數據庫管理和運維人員,DBA 負責數據庫的日常運維工作。當出現問題 SQL 時,DBA 通常首當其衝負責問題診斷。

那麼,什麼是 SQL 問題或者說問題 SQL 呢?從一個更廣泛的定義來看,SQL 問題指影響業務正常運行的各種 SQL 相關問題。比如圖上舉例的案例,它們都可以被歸類爲 SQL 問題。愛可生作爲一家數據庫公司,我們從客戶那裏獲得了大量的反饋,每年都會因爲 SQL 問題導致幾起高級別的生產事故。類似的 SQL 問題導致業務中斷的新聞也時不時會出現。

圖片

對研發人員來說,這些 SQL 問題在開發階段很難被發現,因爲研發的首要任務是保證需求實現。此外,按我們對研發人羣和客戶的調研結果顯示,研發人員在新功能開發階段通常沒有時間對 SQL 進行優化,往往只要能完成需求交付就已經很不錯了。一方面是項目進度壓力大,另一方面研發人員自身水平和經驗也有高有低。所以研發人員很難對所有的 SQL 全面進行優化。下面我們舉一個真實且典型的案例。

一個典型的 SQL 問題案例

圖中有三張表,請注意表的字符集的不同,分別是 UTF8 和 UTF8MB4。

圖片

我們將三張表兩兩進行聯合查詢時,分爲字符集一致和不一致兩種情況。

圖片

當字符集不一致時,從執行計劃中可見進行了全表掃描,表關聯字段未命中索引。

圖片

當每張表有 80 萬條測試數據時,執行時間差異明顯,字符集不一致的 SQL 執行時間達到了 0.9 秒。隨着數據量的增加,該 SQL 的問題會愈加明顯,兩表聯查時表的字符集不匹配會導致查詢效率大幅下降。這就是一個典型的 SQL 問題。

可能你會覺得本案例的 SQL 問題看似不該發生,但我們的團隊曾多次在客戶的生產環境中遇到過類似的情況。但根據大家所掌握的慢 SQL 優化習慣來看,有些引發問題的因素是反直覺的。就本案例也不一定會立刻將問題定位和排查出來。所以,我們需要一種更高效的方式來幫助研發人員解決這類問題。

全方位提高 SQL 質量

SQLE 是一款全方位的 SQL 質量管理平臺,覆蓋開發至生產環境的 SQL 審覈和管理。支持主流的開源、商業、國產數據庫,爲開發和運維提供流程自動化能力,提升 SQL 上線效率,提高數據質量。

圖片 SQLE 於 2021 年 10 月 24 日這個屬於開發者的日子正式開源,至今已經兩年多。我們保持每個月發佈新版本的頻率,不斷更新和迭代產品功能。

圖片 前面的典型 SQL 問題案例,在 SQLE 中如何解決呢?

圖片 根據上圖可見,SQLE 會在相同的情況下觸發審覈規則,快速準確的給出審覈結果。

圖片 在 SQLE 中有非常豐富的 SQL 規則,上面的案例觸發了索引失效類規則中的一條。通過制定一套完善的 SQL 規則規範,是做好 SQL 質量管理的第一步。

做好 SQL 質量管理的第一步

圖片

4.1 如何設計 SQL 規範?

在不同的公司和業務場景下,對 SQL 規範都會有不同的要求。想要設計一款通用的 SQL 質量管理平臺,對於 SQL 規範的設計要做到按需配置。支持通過規則模板給不同的業務配置不同的規則集。不同的規則集應該有分級匹配機制,以避免觸發多條規則產生不同的判斷,人爲對更嚴重的問題優先處理整改。在日常工作中也同樣允許對特例的 SQL 不進行處理,通過白名單的機制跳過 SQL 審覈。

4.2 質量如何量化?

在規則完善後,我們也需要對 SQL 質量處理效果,給人進行量化展示。比如:給 SQL 評分、出《審覈報告》和《統計報表》等。一些管理人員並不關心具體的業務,可以通過量化展示,讓他們快速瞭解項目的整體 SQL 質量趨勢。

4.3 問題如何優化?

當我們通過規則審覈出 SQL 問題並量化之後,就到了整改階段。

目前,SQLE 提供了修改建議(知識庫)和輔助診斷(SQL 分析)來協助 SQL 問題處理。

  • 知識庫:每一條規則都會有一篇文檔,其中包含了規則涉及的背景知識和規則設置的原理和常見解決方案。
  • SQL 分析:使用者在進行 SQL 優化前,會將 SQL 問題涉及到的數據(表結構、索引使用情況、SQL 執行計劃)進行整理,實現輔助診斷。

未來,SQLE 會增加主動優化的功能(SQL 改寫、專用大模型能力引入),敬請期待。

SQL 質量管理具體怎麼做?

在日常工作中有具體如何將 SQL 質量管理的理念落地呢?讓我們先回顧一下軟件生命週期。

拋出一些具體差異,每家公司的軟件開發流程大體上都如圖所示,分爲開發、測試、上線、運維等階段。

站在 SQL 的角度,不同階段的工作:

  • 設計與實現階段:開發人員需要完成表結構和業務邏輯 SQL 的設計;
  • 測試階段:測試人員驗證 SQL 的正確性;
  • 部署與發佈階段:運維人員要對庫表結構和數據的初始化;
  • 生產與運維階段:運維人員要對環境中的 SQL 進行監控,遇到問題、診斷問題、解決問題。

圖片

通過對各階段 SQL 流轉中各崗位工作內容的分析可知,SQL 問題越早解決成本越低!

我們都希望將問題消滅在萌芽中,但我們也無法保證在不同階段都沒有發生的可能性。所以,需要在不同階段都準備對應的審覈手段。

圖片

設計與實現階段

  • 在開發階段完成自助審覈,儘早發現問題。在本階段我們前面說過,開發階段主要任務是完成業務功能的開發,能進行 SQL 審覈的是非常優秀的開發人員。在儘量低成本且不改變開發習慣的同時完成完成自助審覈爲主要需求。
  • SQLE 爲開發人員提供了常用的 IDE 插件、SQL 客戶端和集成 CI/CD 代碼掃描等手段,協助開發人員方便簡介地完成自助審覈。

測試階段

  • 測試人員在該階段已經知道業務運行的具體 SQL,庫表結構,可以更直觀的進行審覈。還可以審覈通過網絡層抓包或者雲平臺提供的審計功能來抓取到具體數據。此階段進行審覈相較其他階段有一定的優勢。

部署與發佈階段

  • 該階段是 SQL 流入生產的一個過程,要實現審覈卡點,對上線流程的控制。很多公司有非常規範專業的 SQL 上線流程,由開發和 DBA 來完成流程中的不同任務。

生產與運維階段

  • 主要是 SQL 上線後的監督工作,如圖所示:採集慢日誌、TopSQL。及時發現生產環境中的問題。

總結

企業如何做好 SQL 質量管理?

相信大家認真閱讀本文,結合自身企業的軟件開發流程現狀,會對這個問題有一個自己的答案。最後,我們以 SQLE 爲例總結如下。在軟件生命週期中以 SQL 流轉的角度,在四個不同的階段通過 建立規範、上線前控制、標準發佈、前控後督,完成閉環漸進式的 SQL 質量提升。

圖片

歡迎大家來體驗 SQLE 社區版 :)

✨ Github:https://github.com/actiontech/sqle

📚 文檔:https://actiontech.github.io/sqle-docs/

💻 官網:https://opensource.actionsky.com/sqle/

更多技術文章,請訪問:https://opensource.actionsky.com/

關於 SQLE

SQLE 是一款全方位的 SQL 質量管理平臺,覆蓋開發至生產環境的 SQL 審覈和管理。支持主流的開源、商業、國產數據庫,爲開發和運維提供流程自動化能力,提升上線效率,提高數據質量。

SQLE 獲取

類型 地址
版本庫 https://github.com/actiontech/sqle
文檔 https://actiontech.github.io/sqle-docs/
發佈信息 https://github.com/actiontech/sqle/releases
數據審覈插件開發文檔 https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章