Bytebase的SQL审核体验（基于MySQL库

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 审核方面的比较：

1. Bytebase

• 支持针对 SQL 代码的审查，同时也支持提交的数据变更的审查；
• 以 pull request 作为审查流程触发器；
• 提供多种审查标准，包括大小写、变量名检查以及 SQL 注释存在等等；
• 集成了 JIRA、GitLab 等协作工具。

1. Archery

• 内置的 SQL 管理系统支持 SQL 审核功能；
• 提供了审核日志和帮助文档等记录和备查功能；
• 支持数据某些特定字段和规则的审核，如手机号码、身份证号、密码等；
• 支持自定义审核规则。

1. 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审核策略

1. 创建基于基础模版的SQL审核策略

先配置Test环境的SQL审核策略

使用模版包括的默认规则，直接点击确认并添加

Prod环境按同样的方法配置，完成后的效果如下

3. 创建项目，并添加数据库导项目中

1. 创建项目

1. 添加项目包含的数据库

点击转移数据库，将docker-compose中默认包含的两个环境的employee库添加到项目中

四、SQL编辑器查询的SQL审核体验

点击左侧SQL编辑器，进入SQL Editor界面，选择Test 环境下的Employee库。在出现编辑创建，敲入select查询语句，可以看着编辑窗口提供了常见IDE的提示功能

下面进行几个常见的查询：

1. 无限制条件查询

   

2. 笛卡尔积查询

   

3. 使用like查询

   

可以看出以上几个Select查询，

1. 对Select语句中未给出Where子句，进行条件限制的，给出了告警
2. 对Select语句中使用select *，未显示指明查询列，给出了告警
3. 对Select语句中where子句，使用like '%xxx'左模糊匹配的，给出了告警
4. 对Select语句中两表关联，漏写关联条件，造成笛卡尔积的，未给出告警或报错

五、变更Schema的SQL审核体验

1. 建表

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审核的需求

1. 基础模版，进阶模版包含的审核规则条数一样，只是进阶模版的要求更加严格些，在基础模版中警告级别的规则，在进阶模版中成了错误级别
2. 对于现有的，但不符合自身业务需求的审核规则，支持在界面可视化环境下进行调整，比如调整规则的级别（错误、警告），部分规则还支持定制检测的内容，这大大方面了管理员对审核规则的定制。
3. 无法自行添加检测规则，满足自身业务需求。比如表连接缺少连接条件，形成笛卡尔积的情况。
4. SQL查询语句，对缺少where条件的SQL，虽然有警告级别的检测，但是还是能够执行查询，对于大表能够参考archery的方式，自动加上limit子句，效果更好些

Database CI/CD | Database DevOps | Schema Migration | Bytebase

数据库变更的场景：flyway，bytebase