干货整理｜SQL 审核最佳实践活动回顾
完整视频大家可以在 Bytebase 视频号的「直播回放」里找到！
SQL 审核 101
「德哥，阿里云 PolarDB 开源生态负责人」
那为什么需要进行审核？比如可能出现删库跑路，执行 `DROP DATABASE`，`DROP TABLE` 等等；或者出现误操作，比如变更的 SQL 忘记加上 WHERE 条件了；或是未经优化的 SQL 发布，业务一上线就直接导致雪崩。所以 SQL 审核主要目的就是可以提前发现风险，避免产生问题。
如何进行 SQL 审核呢？一般来说，有三种方式：
静态规则：根据 SQL 本身定义一些风险等级，但很难穷举
动态规则：结合数据库实时统计信息，估算被评估 SQL 的执行时间、影响行数
基于动态规则 + 辅助输入进行决策：通过输入新增的或取消的 SQL (业务变更后不再需要的 SQL)，返回报告并揭示风险，给出 SQL 的优化建议
对于用户而言，Bytebase, Pigsty 与 PolarDB 的开源社区合作的价值当然在于用户使用 PolarDB 的开源版本可以更加从容了:
科技是第一生产力，Bytebase 把 DBA 的经验产品化后，至少在 SQL 自动审核层面，可以做到人人都具备 DBA 的能力，大幅度降低业务上线带来的 SQL 变更风险
Pigsty 覆盖了数据库实例的生命周期管理的能力，包括规模化部署、备份、恢复、容灾、高可用、监控、优化、诊断等 DBA 常用的需求
生态建设核心的一点，就是重新唤醒大家各自发挥自己的比较优势，来激发开源共同协作的氛围，推动整个产业良性的发展。我非常希望能够看到的一种全新的合作模式，大家能够发挥出自己的比较优势，最终给产业带来的是组织上人才体系的丰富，业务降本增效，文化上共同协作的能力。
👀 小编注：德哥完整的 blogpost 大家可以移步 GitHub (https://github.com/digoal/blog/blob/master/202206/20220628_01.md) 拜读 👏
SQL 现有流程 & 工具
「冯若航，Pigsty 作者/PostgreSQL 布道师」
我有三段经历，分别是在阿里、探探和 Apple 做 PostgreSQL 相关的事情：在探探管理一个 13k 的 PD 集群，220 套数据库；在苹果用了 24 套 PostgreSQL 搭的数据仓库，在 PG 领域也积累了不少经验。
研发想在数据库里做一个变更，首先要 git 仓库里存储数据库的 schema 定义提交一个 PR 到 DBA 这儿，DBA 可以 reject 或 approve，之后 DBA 就人肉（生产环境）或用 Flyway 执行变更，成功后把 PR merge 到 master，表示这个 SQL 变更已经进入到仓库了；如果没有成功，就会 rollback。
SQL 审核最佳实践
「陈天舟，Bytebase CEO 和联合创始人」
在 Google，整个团队用的都是 Google Spanner 数据库，然后所有的团队都用 GitOps。如果要 alter schema，我们会在内部代码平台提交 PR，审核通过它会 check 到代码库里面，但是接下来一步还是需要通过手动的。Spanner 提供了一个 CLI，然后手动完成变更。但是如果要变更一个主键，Spanner 是不允许的（至少我待的四五年里面，从来没有干过这个事情）。
对使用者来说，Spanner 有个非常强的一面，就是它的可运维性质，其实在 Google 内部是没有传统意义上的 DBA 团队，只有一个维护它的 infra 团队，他们每周会有一个小时左右的 office hour，要是有问题的话，可以这时候咨询。除非你的业务真的是出现 P0，P1 的故障了，可能是需要找 DBA，所有其他变更完全都是自助完成。
在蚂蚁，包括整个阿里内部，用的是一个叫做 iDB 的平台（对外就是阿里云上的 DMS），是一个比较经典的工单系统 (当然能力很强大)。iDB 没有类似谷歌 GitOps 的方案，它相对来说还是偏传统的：研发提交一张工单，推进到生产的时候，DBA 进行审核，然后进行变更。
Bytebase 其实就结合了这两个点：基于工单系统和 GitOps 的方案。但是我们在 Google 的方案上面做了创新：Google 有一步是人工手动审核的步骤，审批过后，他得自己用 CLI 调一下；Bytebase 通过 GitLab 的集成把这步给自动化了，提交的 SQL 语句提交到代码仓库之后，通过 webhook 触发会自动在 Bytebase 平台上形成一个工单，会直接进入 DBA 审批的流程。还有一个点在于 Bytebase 和 GitLab 的定位：Bytebase 主要还是由 DBA 来使用，因为 DBA 需要进行线上审核，但是 GitLab 主要由开发或业务团队来管理。通常来说，一个 SQL 变更会有两个阶段：业务团队先进行业务方面的审核，审核通过后，再由 DBA 从 SQL 的规范和数据库层面去审核。所以 Bytebase 其实就是对应着现在公司里面常见的组织关系设计的。
Q&A
Q: 像业界 MySQL 有比较成熟的 SQL 审核方案，PostgreSQL 还比较少，这是有什么难点吗？
A: 难点还是在解析 PostgreSQL SQL 方言的 Parser 上。MySQL 审核方案可以基于 inception 或者直接基于 pingcap/parser 做，PostgreSQL 社区目前还没有成熟的方案。不过这个情况马上将会迎来改变，因为我们内部已经开始自研 PostgreSQL parser。
Q: SQL 审核规则怎么做规则的配置化？
A: Bytebase 现在已经支持 SQL 审核规则的配置化了，DBA 可以在 Bytebase 平台为不同环境配置不同的审核策略。变更执行前，Bytebase 会根据配置的策略自动检查 SQL 语句，如有不符合规则的 SQL 语句，Bytebase 会以警告/错误信息的方式提示用户，并暂停正在执行的 schema 变更，详情请参考适用于 MySQL 的 Schema 审核策略。
Q: 现在的 SQL 语句都是在代码中， DBA 都是事后去分析这些慢查询的，很被动，Bytebase 怎么过滤这种慢查询呢？
A: 现在整个 DevOps 都在讲左移，当然是能越早发现问题越好，这块也在 Bytebase 规划和射程之内，结合代码静态分析去系统化地解决。但估计时间线会稍后一点，请大家再等等。
Q: Bytebase 能否按规则把存储过程分成脚本，达到审核存储过程的目的？
A: 存储过程虽然保存在数据库内，其实本质上是代码，而不是数据。所以管理存储过程，最好的方式其实是走 GitOps / Database-as-Code 的方式，把存储过程保存在代码仓库里。所以这个需求是完全命中 Bytebase VCS 变更流程的设计，现在就可以试一下！
Q: Bytebase 对 PostgreSQL 后续的支持计划是怎么样的？
A: 只要是支持 MySQL 的能力，PostgreSQL 这边后续都会加上。目前因为社区 PostgreSQL 的组件还不及 MySQL，所以在功能点上和 MySQL 有些差距，我们也打算先把这些坑填了，就是要多花一点时间。
Q: 基于你们的产品可以自己二次开发吗？
德哥：这个是必须可以的。PolarDB 是开源的，用的是 Apache 2.0 协议，所以拿去二次开发或者商用都是 OK 的。
冯若航：欢迎大家来奉献！Apache 2.0 协议允许商用，但是请遵循一个 notice 就是你不能说这东西就是你写的，除了这个小小的限制以外，它是非常非常友好的。实际上据我所知，Pigsty 作为运维监控数据库的一个工具是有不少厂商拿去自己用的。
天舟：Bytebase 代码是完全开源的，对于社区版的代码，我们使用的是 MIT 证书。而企业版的功能则需要购买企业版后才能使用。在遵循使用协议的情况下，二次开发是没有问题的。而且我们在设计的时候，也是专门架构成面向二次开发友好的，比如我们引入 namespace，插件化架构等。比如说如果想集成一个 Bytebase 目前还不支持的数据库类型，只要实现我们定义的 database driver 接口就行。
参考链接
迟来的作业 —— HashiConf Europe 2022 我的走马观花
Bytebase 加入阿里云 PolarDB 开源数据库社区