背景

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优化建议等.

• 希望能支持快速闪回, 变更快速回退能力.
• 希望支持定时变更, 无人值守变更. 解放劳动力.