【DB吐槽大會】第51期 - 缺乏SQL審查功能

背景

1、産品的問題點

• 缺乏SQL審查功能

2、問題點背後涉及的技術原理

• 業務上線通常伴随SQL的變更、新增或DDL操作等. 這些資料庫操作有什麼風險? 在大多數時候取決于開發者或DBA的判斷. 例如:

• • SQL的基準是什麼? 吞吐訴求、RT訴求. 資料庫是否滿足業務需求?
  • 新增的SQL會不會導緻資料庫性能瓶頸, 并且影響已有業務.
  • SQL 是不是處于優化執行路徑? 需不需要加索引? 需不需要加hint? 需不需要改寫SQL等? 需不需要鎖表? 需不需要在低峰期操作?
  • 回退預案是什麼?
  • 操作流程是什麼?
  • 哪些操作有删庫跑路風險? 例如DROP或truncate的DDL、沒有條件或條件絕對為true的update或delete.

3、這個問題将影響哪些行業以及業務場景

• 通用

4、會導緻什麼問題?

• 沒有SQL審查功能, 每次業務上線都是提着腦袋在幹. 随時有删庫跑路、業務雪崩等風險.

5、業務上應該如何避免這個坑

• 規範操作流程
• 增加變更審查流程
• 增加回退預案
• 增加備份流程

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 人力成本增加, 同時取決于審查人員的責任心、經驗、技術能力等. 同樣存在風險.

7、資料庫未來産品疊代如何修複這個坑

• 希望在核心層面支援SQL 審查功能.

• • 輸入SQL、并發、吞吐、RT等訴求.
  • 傳回報告: 評估變更的耗時, SQL的模拟QPS和RT, 資料庫的資源消耗等.
  • 揭示風險, 例如無法滿足RT|QPS預期、資源打滿、删庫跑路、雪崩 等風險.
  • 給出SQL優化建議等.

• 希望能支援快速閃回, 變更快速回退能力.
• 希望支援定時變更, 無人值守變更. 解放勞動力.

https://github.com/digoal/blog/blob/master/202109/20210928_03.md#postgresql-%E8%AE%B8%E6%84%BF%E9%93%BE%E6%8E%A5 https://github.com/digoal/blog/issues/76