SQL审核的整体设计和落地

这是学习笔记的第 1734 篇文章

SQL审核目前已做差不多了，整个过程其实看起来，要远比我们想的c/s服务调用要复杂的多。

这是我整理的一个初版的SQL审核项目实现逻辑，在这个基础上可以做很多的改进甚至贴心的小功能。

首先来解释下这个图。这个图里我特意标记了序号，可以看到一个SQL审核的需求从发起到最后返回，整个过程可能比我描述的还要多，我列出几个重要步骤来。

首先是前端，审核的需求从哪里发起，期望是有一个通用的入口，那么在没有建设完善前，那应该有一个迭代的过程，首先要具备基本的SQL审核调用服务。而对于前端的建议就是我们需要找一个通用入口，但是我们也依然可以保留本地的前端，方便调用和测试使用，最终的业务目标就是把它打造成一个小巧的工具，是提供给开发的自助服务小工具。

如果要涉及到外部系统，那么显然我们要封装API了。这个API有两个难点，我们要解析传送的SQL和其他属性信息，另外一个就是API层来对接后端的服务和结果回调。

这里需要提一下，就是步骤3，我们要充分利用已有的元数据，如果需要做业务数据验证，比如输入了主库的IP，我们需要根据元数据映射关系，来匹配到从库，完成审核任务，语法语义审核在从库端，至于后续要做的自动化上线，则逻辑需要定制改动。

整个SQL审核服务怎么部署，我们可以在一台中控服务器端部署一次即可，然后在各个数据库服务器上创建相应的账户即可。至于权限，在审核层面，我们只需要开放select权限即可。

在经过审核服务的审核之后，会推送审核结果到API服务端，这个过程是审核服务的核心，这个核心的意思是我们要从逻辑上完全可控，这可以分为两个层面的工作：一个是充分吸收已有的审核工具的优势，另外就是对审核逻辑进行针对性的定制，定制分为两部分，分别是审核信息的定制和审核逻辑的定制。

这个过程看起来已经比较完整了，其实我们只走完了审核工作的70%的工作。

为什么这么说，其实如果我们不够重视，会很吃亏，如果一个开发经验不够丰富，那么它提交的SQL肯定会有很大的建议，我么测试的情况，有的SQL语句会有高达40条审核建议，如果一个人对于审核服务还比较陌生的话，从他第一次接触就基本会有一个不大好的印象，工具不好用，华而不实，建议和规范难以落实。

怎么能够尽可能落实呢，其实我们可以想想，一下子给我几十条建议，任何人开始都吃不消，那么建议这么多，有没有优先级呢，哪些建议是明显的错误，或者本身违背基本规范，那么我们就要指出来，比如表的字符集不符合标准，表名大小写混合等等，字段名是关键字等，这些就没有什么商量的，不可以。 这一类信息是要筛选出来的，要重点提示。

而第二类信息是潜在的问题，比如使用了不建议的数据类型（lob）,timestamp类型的范围有限等等，这些信息的意义更大，能够尽可能的杜绝潜在的问题。

第三类问题是改进建议型信息，比如表字段的注释，可能我们没办法要求所有的开发都提交的字段都有注释，或者设置了默认值，但是我们可以作为改进和建议提出来。

这些信息怎么来映射，其实就和审核服务里的提示信息是密切关联起来的，审核服务里面有个error_code,我们可以根据这个error_code来分级。 然后把信息都归类到不同的类别里面，根据优先度来显示出来。

后期要做的而就是我们可以根据审核的建议信息，把这个调用信息做到持久化，包括SQL,包括审核建议，然后一定的时间范围内做下对比和跟进，看看哪些建议还不够好，哪些可以继续改进。

在这个基础上就可以考虑邮件甚至其他更好的方式了，我们可以做一些数据分析或者反馈，通过比较友好的方式推送出去，或者做成打分系统，让这个过程更透明。