这是学习笔记的第 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,包括审核建议，而后肯定的时间范围内做下比照和跟进，看看哪些建议还不够好，哪些可以继续改进。

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