SQL审核的落地的正确姿势
SQL审核的落地的正确姿势
这是学习笔记的第 1771篇文章
SQL审核这个概念在近些年来被提得蛮火，算是和SQL优化在同一个量级的业务需求。
我们先来说下SQL审核的意义，要回答这个问题，就需要先解答下为什么要引入SQL审核，大多数情况下，人工审核SQL的代价太高；而且在规范落地和jian监督约束方面难以把控；大多数情况下，性能隐患会给线上环境带来极大的影响，可能是影响业务使用，也可能直接关系数据；规范落地没有一种数字化可视化的支持方式，落实规范基本靠拍脑袋想。
所以行业里也存在一些审核工具，比如Inception,SQL Advisor等，当然我们在此不着重介绍这些审核工具的细节，而是基于业务的场景来考虑。
对于SQL审核来说，我认为要它的核心是：
1）对业务同学来说，SQL审核是对标一种自助服务
2）我们不刻意做语法审核，专注于SQL规范的审核
而审核的难点更多是基于公司规范定制审核规则，有很多工具，方案，如果把基于自己特定业务的规范揉入进来，这是一个值得深思的问题。
理解了我所强调的核心，边界问题就相对清晰了，所以SQL审核这件事情，其实说简单也可以很简单，要说复杂，体系也可以很庞大。
一般来说，审核会覆盖几个维度：DDL, DML,DQL
他们的明细信息如下：
DDL：
Create
Alter:
alter table ** add
alter table ** change
alter table ** drop
alter table ** modify
Drop，
Truncate
DML：
Insert:
insert into ** values(xxx)，(xxx);
insert into ** select
insert into ** set
Update
Delete
DQL：
select **
select ** inner join
select ** union all
这样一些类别的SQL语句，我认为在初期或者要落地SQL规范，那么方向一定是先从DDL入手，也就是通泛的create语句和alter语句。
而对于查询语句而言，他们在规范方面可参考的信息很有限，所以更多会是在性能和安全方面做考量，所以基于查询，可以后续去补充通用查询模块，而DML的审核，在大多数情况下，应用是完全有权限修改数据的，在这个层面支持审核的意义我觉得更多是基于DML的闪回（即先得有备份）。所以从这些场景入手，可以基本明确，我们的大多数需求还是创建类的。
整个SQL审核的设计，本质是基于规范来完成，而作为一个工具或者产品，它一定有一些深耕的特性或者可以拿得出手的地方。大体来说，会有如下的四个亮点，也是在迭代开放的过程中初步沉淀下来的。
简单来解释下，审核信息的分级配置就是，一条SQL语句，可以通过审核工具给出多条建议，比如有20条建议，这些建议如果直接抛给业务同学，很可能会被忽略，所以对于业务同学来说，我们可以根据优先级来给出建议，哪些是必须遵守的，哪些是有潜在问题，哪些是建议改进的。
对于SQL质量，可以使用可视化的方式来对接，比如通过打分系统来把SQL质量数字化，通过看板的方式把数字可视化。
SQL质量跟踪，是我们的审核工具应该是迭代完善的，在使用的过程中，我们应该尽可能保留审核的明细信息，在后续对这些建议进行跟进和完善，这是一种反馈式的互动。
在可视化方面，如果把数字可视化，其实可以看到很多有趣的信息，比如通过这种方式可以看到在一段时间里，SQL审核的次数，每天审核的SQL质量，通过平均分来做统计分析，可以对工具整体的落地方向有一个整体的把控。
而在后续，如果继续落地SQL规范，基本有下面的一些思路。
- 完善已有的资源：补充SQL开发规范和持续分享
- 对接工单流程，通过工单中嵌入自动化审核，如果分数在70分以下警告，分数低需要标注原因，这样一来，工单的审批才会有理有据
- 提供SQL审核质量分析和数据报告，提供定向建议
- 自动化上线
- 通用查询
- SQL优化工具
换句话来说，SQL审核的终极目标是没有审核，看起来这个不可能实现，其实从罐头上把问题解决掉，整个局面就打开了。比如有些公司中，是统一了数据库对象级别的操作，都是通过配置文件的方式来对接，SQL语句是自动编译生成，这就从架构层面解决了很多前期潜在的的SQL问题。