Bytebase的SQL审核体验（基于MySQL库）
一、关于我
我是DBA，想看看 SQL审核 的完成度，衡量 Bytebase 对日常SQL工单提审能够提供的帮助有多大。
二、什么是Bytebase
按官网上的描述，Bytebase是一款为DevOps团队准备的数据库CI/CD工具，专为开发者和DBA打造。唯一被CNCF Landscape收录的Database CI/CD产品。
其核心理念就是，像管理代码一样管理SQL。而对于SQL脚本的管理，其中最重要的部分就是SQL审核。
目前市面上主流的SQL审核产品，主要有Archery、Yearning、Bytebase，三者都是用于 SQL 审核的开源平台，这里是它们之间 SQL 审核方面的比较：
- Bytebase
- 支持针对 SQL 代码的审查，同时也支持提交的数据变更的审查；
- 以 pull request 作为审查流程触发器；
- 提供多种审查标准，包括大小写、变量名检查以及 SQL 注释存在等等；
- 集成了 JIRA、GitLab 等协作工具。
- Archery
- 内置的 SQL 管理系统支持 SQL 审核功能；
- 提供了审核日志和帮助文档等记录和备查功能；
- 支持数据某些特定字段和规则的审核，如手机号码、身份证号、密码等；
- 支持自定义审核规则。
- Yearning
- 提供了 SQL 查询优化的框架；
- 支持 SQL 查询分析、慢查询机制、查看 SQL 执行计划；
- 可以根据分析的结果对 SQL 进行优化；
- 支持审核过滤器，可过滤掉某些无用的 SQL。
总体来说，三者的差异在于它们的实现方式和功能重点。Bytebase 致力于代码审查和数据审查的结合，Archery 着重于 SQL 数据管理和自定义规则等审核方面，Yearning 则聚焦于 SQL 查询优化这一点。选择适合自己场景的工具，截获 SQL 问题，优化查询性能，提高操作效率。
本文主要体验Bytebase的SQL审核部分
三、Bytebase部署
1. docker部署
简化起见，这里使用docker-compose方式部署
curl -fsS https://raw.githubusercontent.com/bytebase/bytebase/main/quickstart/getting-started.docker-compose.yml | BB_VERSION=1.16.0 docker-compose -f - up -d
部署完后，启动docker，完成后的情况如下：
root@mytest-1226:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
78e8a0a8f05d bytebase/bytebase:1.16.0 "bytebase --data /va…" 7 minutes ago Up 7 minutes (health: starting) 0.0.0.0:5678->5678/tcp, :::5678->5678/tcp bytebase
811f037ffc01 bytebase/sample-database:mysql-employee-small "/entrypoint.sh mysq…" 7 minutes ago Up 7 minutes (healthy) 33060-33061/tcp, 0.0.0.0:3307->3306/tcp, :::3307->3306/tcp root-employee-test-1
53e262c73f7b bytebase/sample-database:mysql-employee-small "/entrypoint.sh mysq…" 7 minutes ago Up 7 minutes (healthy) 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060-33061/tcp root-employee-prod-1
部署完成后，登录Bytebase，配置管理员账号，管理的数据库实例，这些部分参考官方文档 一步一步操作。
2. 配置SQL审核策略
Bytebase默认两个环境: Test, Prod ，可以针对两个环境分别配置SQL审核策略。
实际上在现实环境中，为了提前发现SQL问题，避免把问题带到线上，会要求测试环境和线上环境的配置保持一致，故这里调整SQL审核策略
- 创建基于基础模版的SQL审核策略
先配置Test环境的SQL审核策略
使用模版包括的默认规则，直接点击确认并添加
Prod环境按同样的方法配置，完成后的效果如下
3. 创建项目，并添加数据库导项目中
- 创建项目
- 添加项目包含的数据库
点击转移数据库，将docker-compose中默认包含的两个环境的employee库添加到项目中
四、SQL编辑器查询的SQL审核体验
点击左侧SQL编辑器，进入SQL Editor界面，选择Test 环境下的Employee库。在出现编辑创建，敲入select查询语句，可以看着编辑窗口提供了常见IDE的提示功能
下面进行几个常见的查询：
-
无限制条件查询
-
笛卡尔积查询
-
使用like查询
可以看出以上几个Select查询，
- 对Select语句中未给出Where子句，进行条件限制的，给出了告警
- 对Select语句中使用
select *，未显示指明查询列，给出了告警 - 对Select语句中where子句，使用
like '%xxx'左模糊匹配的，给出了告警 - 对Select语句中两表关联，漏写关联条件，造成笛卡尔积的，未给出告警或报错
五、变更Schema的SQL审核体验
1. 建表
- 点击变更Schema，填写ddl语句
可以看到ddl语句提交后，自动进行检查，SQL审核按钮前出现惊叹号，点击查看
按检查审核项目要求，修改调整ddl语句
此时SQL审核中显示的告警错误如下：
第三项索引，属于错误，需要解决。查看规则详情
可以看到，这里定义的主键列类型有误。我这里是MySQL数据库，虽然语法上支持SERIAL/BIGSERIAL，但是不太符合日常使用习惯，这里做下调整。
在SQL审核策略部分，找到需要调整的审核项，点击编辑
添加MySQL中常用的主键类型：INT, BIGINT，点击确认
然后点击最下方的确认更新，更新策略
回到刚才的工单，手动执行运行检查
只剩两个告警项，这里测试就暂时忽略，实际使用时最好根据提示要求修改。
点击发布按钮，填写说明信息后，点击确定。
可以看到，工单在执行阶段，有出现错误。这是因为我这里对自增id定义了错误的默认值，继续调整。
重新发布后，可以看到ddl语句正确通过审核。由于我是使用admin账号提交的SQL，属于所有者用户，不用走审批流程，直接执行了。
执行完成后，可以通过界面直接看到：Test-employee-t1
2. 修改表结构
测试表添加字段，修改现有字段类型
查看SQL审核结果
居然禁止修改列类型，这个不符合实际业务需求，需要调整规则，改成警告级别
对上面的ddl语句进行调整，满足SQL审核的大部分要求
上述两个警告性信息，可以接收，提交工单
六、系统自带SQL审核模版
Bytebase SQL审核中自带了三个模版，包括样例模版，基本模版 和 进阶模版，样例模版过于简单，只能做个人实验环境使用，不能用于业务环境，这里主要看后面两个模版。
1. 基本模版
基本模版中一共包括49条规则，其中15条规则是错误级别的。对这几条规则，我们逐一考察一下：
| 范围 | 规则描述 | 是否 满足需求 | 是否支持等级定制 | 是否支持检测内容定制 |
|---|---|---|---|---|
| 数据库 | 禁止删除非空数据库 | 是 | 是 | 否 |
| 列 | 禁止修改列类型 | 否 | 是 | 否 |
| 列 | 强制 “NOT NULL” 列设置默认值 | 是 | 是 | 否 |
| 列 | 禁止使用 “CHANGE COLUMN” 语句 | 是 | 是 | 否 |
| 列 | 禁止修改表中的列顺序 | 是 | 是 | 否 |
| 列 | 强制自增列使用整数类型 | 是 | 是 | 否 |
| 列 | 禁止在列属性中定义字符集 | 是 | 是 | 否 |
| 列 | 强制自增列使用 “UNSIGNED” 类型 | 是 | 是 | 否 |
| 表 | 强制表包含主键 | 是 | 是 | 否 |
| 表 | 限制待删除表的命名格式 | 是 | 是 | 是 |
| 表 | 禁止使用分区表 | 否 | 是 | 否 |
| 索引 | 禁止索引包含重复列 | 是 | 是 | 否 |
| 索引 | 禁止对 “BLOB” 与 “TEXT” 类型列创建索引 | 是 | 是 | 否 |
| 索引 | 允许主键使用的类型列表 | 否 | 是 | 是 |
| 引擎 | 强制使用 InnoDB 存储引擎 | 是 | 是 | 否 |
存在部分错误级别的规则，不是很符合业务需求，不过由于支持对其级别进行调整的，所以基本上还是能够满足日常业务DDL变更操作
2. 进阶模版
进阶模版中一共包括49条规则，其中31条规则是错误级别的。
对比基础模版可以发现，两个模版的规则条数一致，只是要求严格了些，将其部分警告级别的规则，调整为错误级别。
| 范围 | 规则描述 | 是否满足需求 | 是否支持等级定制 | 是否支持检测内容定制 |
|---|---|---|---|---|
| 数据库 | 禁止删除非空数据库 | 是 | 是 | 否 |
| 系统 | 允许使用的字符集（Charset）列表 | 是 | 是 | 是 |
| 系统 | 允许使用的字符序（Collation）列表 | 是 | 是 | 是 |
| 列 | 禁止使用的列类型列表 | 是 | 是 | 是 |
| 列 | 禁止修改列类型 | 否 | 是 | 否 |
| 列 | 强制 “NOT NULL” 列设置默认值 | 是 | 是 | 否 |
| 列 | 禁止使用 “CHANGE COLUMN” 语句 | 是 | 是 | 否 |
| 列 | 禁止修改表中的列顺序 | 是 | 是 | 否 |
| 列 | 强制自增列使用整数类型 | 是 | 是 | 否 |
| 列 | 禁止在列属性中定义字符集 | 是 | 是 | 否 |
| 列 | 强制自增列使用 “UNSIGNED” 类型 | 是 | 是 | 否 |
| 列 | 强制列增加注释并限制长度 | 是 | 是 | 是 |
| 表 | 强制表包含主键 | 是 | 是 | 否 |
| 表 | 禁止使用外键约束 | 是 | 是 | 否 |
| 表 | 限制待删除表的命名格式 | 是 | 是 | 是 |
| 表 | 禁止使用分区表 | 否 | 是 | 否 |
| 表 | 注释检查 | 是 | 是 | 是 |
| 语句 | 禁止使用 “SELECT *” | 是 | 是 | 否 |
| 语句 | 强制语句带有 “WHERE” 条件 | 是 | 是 | 否 |
| 语句 | 禁止过滤条件使用左模糊匹配 | 是 | 是 | 否 |
| 语句 | 禁止显式 “COMMIT” | 是 | 是 | 否 |
| 语句 | 禁止在 DML 语句中使用 “LIMIT” | 是 | 是 | 否 |
| 语句 | 禁止在 “UPDATE”,“DELETE” 语句中使用 “ORDER BY” | 是 | 是 | 否 |
| 语句 | 禁止对同一张表发起多次独立变更 | 是 | 是 | 否 |
| 语句 | 强制 “INSERT” 语句显示指定列名 | 是 | 是 | 否 |
| 语句 | 禁止在 “INSERT” 语句中使用 “ORDER BY RAND()” | 是 | 是 | 否 |
| 索引 | 禁止索引包含重复列 | 是 | 是 | 否 |
| 索引 | 禁止对 “BLOB” 与 “TEXT” 类型列创建索引 | 是 | 是 | 否 |
| 索引 | 主键类型限制 | 是 | 是 | 否 |
| 索引 | 允许主键使用的类型列表 | 否 | 是 | 是 |
| 引擎 | 强制使用 InnoDB 存储引擎 | 是 | 是 | 是 |
基本上能够满足业务开发过程中的对SQL语句审核规则要求
七、总结
Bytebase的SQL审核模版中自带的审核规则，针对日常SQL查询、DDL变更中遇到的常见问题进行了梳理，整理出了基础模版和进阶模版，基本上能够满足了日常对SQL审核的需求
- 基础模版，进阶模版包含的审核规则条数一样，只是进阶模版的要求更加严格些，在基础模版中警告级别的规则，在进阶模版中成了错误级别
- 对于现有的，但不符合自身业务需求的审核规则，支持在界面可视化环境下进行调整，比如调整规则的级别（错误、警告），部分规则还支持定制检测的内容，这大大方面了管理员对审核规则的定制。
- 无法自行添加检测规则，满足自身业务需求。比如表连接缺少连接条件，形成笛卡尔积的情况。
- SQL查询语句，对缺少where条件的SQL，虽然有警告级别的检测，但是还是能够执行查询，对于大表能够参考archery的方式，自动加上limit子句，效果更好些
