近在搞SQL 审核的工作，从开始到目前有3个月的时间，

随着时间的推移从想法很简单认为这个事情很简单，到目前

的认知，还是希望能分享一下。

首先SQL审核到底是从技术入手，还是从规范入手，甚至从

管理制度入手，这终会导致你的项目的影响力和后的成

功的概率比。

为什么要进行SQL审核,答案可以归结为

1 公司的规模比较大,已经到了通过人工无法进行审核保证SQL符合一定的规范和安全的需要,整体的控制处于失控的状态

2  公司本身没有SQL 审核的流程,想通过软件达到规范开发SQL撰写,提高软件质量,以及开发SQL 可控的理想状态

在从三个角度来阐述前，先将SQL 审核 和 数据库审计分清

楚, SQL 审核核心是针对开发上线的SQL语句进行检测, 数据

库审计是针对DBA 或运维人员对数据库的操作进行检测和记

录,方便后面找问题(清算某些不规范的操作).所以这两个东西

没有任何关系, 针对的人员和场景都是不同的,工作的原理和

部署的方式和管理制度都是不同的.

所以我们今天要说的是SQL审核,是针对开发和项目规范,保证

软件上线的质量的一种工作方式和方法的统称.

下面从三个角度来看SQL审核

1  技术层面, 从技术层面来看,SQL 软件要达标的满足以下几点

     1.1  SQL 审核软件的支持的数据库种类的问题

     1.2  SQL 审核软件安装的便利性和侵入性的问题

     1.3  事前审核的接入的问题

     1.4  事后审核方法的问题

     1.5  软件是否带有流程模块,或对接相关其他的OA系统

     1.6  软件是否能进行简单的自定义的规则的工作

     1.7  软件其他附加的功能,如慢查询监控,或者历史记

录, SQL自动执行和定 时执行,白名单,旁路审核, 数据库容量

提示和特殊语句的给出等等

      1.8 与现行的开发系统对接,例如 Jekenis , mybatis, 

openAPI 等方面的支持和自动获取SQL 语句的方式.

从技术的层面来看SQL 审核, 其实能完全能满足功能的自研,

或者外部购买的系统都未必能满足以上的所有要求, 但考虑

这些要求是,SQL 审核的核心吗

     1.9  SQL审核可视化,可度量化,可历史化的功能需求

SQL审核的核心到底是什么?

SQL 审核的核心, ---- 规则

规则是什么,可以表述为SQL的规范. 那么每个单位的SQL

的规范是一致的吗,或者大部分都一致吗?  经过我们这几个月

的调研和供应商的沟通中,发现了其中的问题, 规则基本上多

数银行的规则都不一样,有的大型银行只有15条规则, 有

的可能有几十条, 那么规则是越多越好,大多数人的想法估计

是的,规则自然是越多越好,管理的越严格越好. 实际上我们并

不是这样认为的,可落地的规则,深入人心规则是初步推进项目

好的规则,切记贪大求全.

例如:我们下面列一些规则看看如何

1   MYSQL SQL 中不允许一个表查询在一个SQL 出现两次的情况  (其实就是查询和子查询都带有这个表)

2   POSTGRESQL 不允许使用CHAR 模式的字段

3   MONGODB 不能出现没有ISODATE的collection

当然这上面的原理和来源就不说了,懂得自然懂.

那么规则在实现中遇到大的问题是什么, 我们认为规则守不

住就是大的问题,这说明两个问题, 

1 制定的规则本身就有问题

2 目前的规则对于目前的开发水平,要求过高

 例如 上面MYSQL 的规则,实际上有些语句通过添加索引,也

可以进行相关的优化和问题的解决,那么这样的规则在初期可

以有,也可以没有, 当我们发现系统中由于没有这个规则,引起

了问题后,我们在将问题,反哺规则,这样规则的说服力就大了.

那么规则就可以分为两种  

1  与数据库性能有关的   (包含表设计)

2  与数据库性能无关  例如库名必须小写,  表名必须小写, 这

些和性能没有什么关系,和整体的规划和计划有关.

那么有了规则,SQL 审核软件实施起来就没有后顾之忧了?  

NO NO NO , 其实SQL 审核软件实施关键的问题是管

理.

不少单位都想通过SQL 审核软件来改变软件质量差,软件质

量在数据库方面无法把控的情况, 但恰恰忘记了一点, 终这

个软件如何进行实施,和落地的问题,规则列了一大堆,终还

是没有控制住软件的SQL质量.

那么这个事情就又能讲出一个故事,关于如何实施的事情,实施

本身又能分出三种类型

1   事前审核

2   事中审核

3   事后审核

三种实施的方式各有各的好处和特点,也有各自的无奈, 大部

分SQL软件的供应商都推荐事前审核, 事前审核就是在软件开

发的初期, 就将SQL 审核软件介入,边开发边审核,在终交付

上线的时候,给付的软件在SQL方面是基本合格的.

事中审核,其实可以理解为在UAT系统部署要测试软件的过

程中,提供SQL语句,或者在上线UAT后,通过软件来扫描系统

正在运行的语句.通过这个过程发现问题,修改问题

事后审核,在系统上线后,对系统进行扫描,发现有问题的语句,

并进行修改.

大部分银行也认为自己应该通过事前审核的方式介入管理, 可

问题在于管理和各种非技术的问题,导致事前审核无法落地, 

例如数据库组织在公司IT部门内部,没有分量,说话和放屁一样,

那么事前审核能行得通的可能性就比较低,并且没有对开发的

要求,或者项目并未对此有要求,做到事前审核的可能性就更低

了.

事中审核,事中审核可能是大部分公司的现状,在做用户测试的

时候,开始提交SQL审核,并且在系统内进行扫描,发现问题,提

出问题,解决问题. 看上去也很美,可软件设计中有些SQL是无

法更改的, 主要的原因也可以从,技术本身,和 技术以外两个方

面考虑.

技术本身,一个表设计已经定了,那么SQL的撰写的方式也大部

分定了,如果在审核过程中,发现问题,想改可能就比较困难,没

有那么方便了.

技术以外, 那就是管理的问题,SQL 改写可能消耗项目的时间, 

不改后期埋雷,权衡利弊项目上线的时间与改不改就和SQL审

核软件没有什么关系了,和整体的流程和管理有关

事后审核,事后审核其实是一个亡羊补牢的过程,基本上这个时

间在做审核的意义在于将不得不改的,影响核心系统的性能的

问题抛出, 来算算账, 让之前那些放过这些问题SQL 的设计人

员 "肉疼" 一下.  此时能改的就改改,不能改的,那就的想想特

殊手段,做好长时间持久战的问题了,以及怎么应对客户可能投

诉的问题了.

经过几个月的努力,也总结了一些市面常见的主流的SQL审核

系统功能特点,以及"缺陷".  至于规范制度和管理,我们

也大致心里有了 1 2.

那么SQL 审核到底审了个什么 !

下图是一个工作的过程