CN104391995A - 一种sql语句审核的方法、数据库运维的方法及系统 - Google Patents

Abstract

一种SQL语句审核的方法、数据库运维的方法及系统，本申请提供了一种SQL语句审核的方法，包括：确定目标SQL语句；分别对所述目标SQL语句进行语法和语义分析，按照预设的语法规则对所述目标SQL语句进行语法分析；若所述目标SQL语句不满足所述预设的语法规则，则报错；存储所述不满足预设的语法规则的目标SQL语句；判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错；存储所述不满足预设的语义分析规则的目标SQL语句。本申请只需要预先设置好审核需要的各种预设规则，以及审核的算法，即可以按照所述算法及所述各种预设规则执行所述SQL语句的审核过程，无需DBA去和开发人员交流SQL语句的问题及修改情况，提高了审核的效率。

Description

一种SQL语句审核的方法、数据库运维的方法及系统

技术领域

本申请涉及运维领域，特别涉及一种SQL语句审核的方法、数据库运维的方法及系统。

背景技术

随着技术的发展，人们对SQL语句的审核以及数据库的运维的方法要求越来越高。

现有的对SQL语句进行审核的方法，一般都是通过数据库管理人员DBA进行SQL的审核工作，DBA需要投入更多的经历去和开发人员交流SQL语句的问题及修改，这样就增加了DBA的负担，并且降低了DBA的工作效率，进而降低了数据库的运维效率。

因此，如何有效的进行SQL语句的审核以及提高数据库运维的效率是本领域技术人员目前需要解决的技术问题。

发明内容

本申请所要解决的技术问题是提供一种SQL语句审核的方法、数据库运维的方法及系统，解决了现有技术中DBA审核SQL语句效率低以及数据库运维效率低的问题。

其具体方案如下：

一种SQL语句审核的方法，该方法包括：

确定目标SQL语句；

按照预设的语法规则对所述目标SQL语句进行语法分析；

若所述目标SQL语句不满足所述预设的语法规则，则报错；

存储所述不满足预设的语法规则的目标SQL语句；

判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错；

存储所述不满足预设的语义分析规则的目标SQL语句。

上述的方法，优选的，还包括：

将所述存储的不满足预设的语法规则的目标SQL语句和所述存储不满足预设的语义分析规则的目标SQL语句以结果集的方式进行显示。

一种SQL语句审核的系统，该系统包括：

确定单元，用于确定目标SQL语句；

分析单元，用于按照预设的语法规则对所述目标SQL语句进行语法分析；

报错单元，用于若所述目标SQL语句不满足所述预设的语法规则，则报错；

第一存储单元，用于存储所述不满足预设的语法规则的目标SQL语句；

判断单元，用于判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错；

第二存储单元，用于存储所述不满足预设的语义分析规则的目标SQL语句。

上述的系统，优选的，还包括：

显示单元，用于将所述存储的不满足预设的语法规则的目标SQL语句和所述存储不满足预设的语义分析规则的目标SQL语句以结果集的方式进行显示。

一种数据库运维的方法，该方法包括：

确定目标SQL语句；

对所述目标SQL语句进行审核；

判断所述审核是否完成，若是，则按照预设条件判断所述审核是否通过，若是，则存储所述审核通过的目标SQL语句；

判断是否需要执行所述审核通过的目标SQL语句，若是，则逐条执行所述审核通过的目标SQL语句；

判断所述审核通过的目标SQL语句的执行是否出错，若是，则判断是否执行force，若是，则继续执行下一条目标SQL语句，直到所有目标SQL语句均执行完毕，若否，则显示结果集。

上述的方法，优选的，在所述逐条执行审核通过的目标SQL语句时，还包括：

获取thread_id信息以及每条所述目标SQL语句执行前后的binlog位置信息。

上述的方法，优选的，还包括：

判断是否需要进行备份，若是，则按照预设的过滤规则过滤所述获取的binlog位置信息，得到当前执行语句的binlog位置信息；

提取所述当前执行语句的binlog位置信息，并解析所述binlog位置信息，得到所述当前执行语句对应的回滚语句；

判断所述备份是否完成，若否，则继续依次执行过滤、提取、解析的过程以及判断的过程，直到备份完成。

一种数据库运维的系统，该系统包括：

确定单元，用于确定目标SQL语句；

审核单元，用于对所述目标SQL语句进行审核；

第一判断单元，用于判断所述审核是否完成，若是，则按照预设条件判断所述审核是否通过，若是，则存储所述审核通过的目标SQL语句；

第二判断单元，用于判断是否需要执行所述审核通过的目标SQL语句，若是，则逐条执行所述审核通过的目标SQL语句；

第三判断单元，用于判断所述审核通过的目标SQL语句的执行是否出错，若是，则判断是否执行force，若是，则继续执行下一条目标SQL语句，直到所有目标SQL语句均执行完毕，若否，则显示结果集。

上述的系统，优选的，还包括：

获取单元，用于获取thread_id信息以及每条所述目标SQL语句执行前后的binlog位置信息。

上述的系统，优选的，还包括：

第四判断单元，用于判断是否需要进行备份，若是，则按照预设的过滤规则过滤所述获取的binlog位置信息，得到当前执行语句的binlog位置信息；

回滚单元，用于提取所述当前执行语句的binlog位置信息，并解析所述binlog位置信息，得到所述当前执行语句对应的回滚语句；

第五判断单元，用于判断所述备份是否完成，若否，则继续依次执行过滤、提取、解析的过程以及判断的过程，直到备份完成。

本申请提供的一种SQL语句审核的方法，首先确定目标SQL语句；然后分别对所述目标SQL语句进行语法和语义分析，按照预设的语法规则对所述目标SQL语句进行语法分析；若所述目标SQL语句不满足所述预设的语法规则，则报错；存储所述不满足预设的语法规则的目标SQL语句；判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错；存储所述不满足预设的语义分析规则的目标SQL语句。本申请只需要预先设置好审核需要的各种预设规则，以及审核的算法，即可以按照所述算法及所述各种预设规则执行所述SQL语句的审核过程，无需DBA去和开发人员交流SQL语句的问题及修改情况，提高了审核的效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的一种SQL语句审核的方法实施例1的流程图；

图2为本申请的一种SQL语句审核的系统实施例1的结构示意图；

图3是本申请的一种数据库运维的方法实施例1的流程图；

图4是本申请的一种数据库运维的方法实施例2的流程图；

图5是本申请的一种数据库运维的系统实施例1的结构示意图；

图6是本申请的一种数据库运维的系统实施例2的结构示意图。

具体实施方式

本发明的核心是提供一种SQL语句审核的方法、数据库运维的方法及系统，解决了现有技术中DBA审核SQL语句效率低以及数据库运维效率低的问题。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参考图1，示出了本申请一种SQL语句审核的方法实施例1的流程图，可以包括以下步骤：

步骤S101：确定目标SQL语句。

首先确定待进行审核的数据库中的目标SQL语句，所述目标SQL语句可以包含一条SQL语句，也可以包含多条SQL语句。

步骤S102：按照预设的语法规则对所述目标SQL语句进行语法分析。

在对所述目标SQL语句进行语法分析时，首先设定预设的语法规则，且所述语法规则和MySQL的语法规则完美兼容，这样审核的准确度非常高。

同时还设置了一些新的语法规则，通过这些预设的语法规则和设置的新的语法规则进行语法分析后，可以完全杜绝了一些已知的具有很高风险的SQL语句的出现，同时不再会出现一些低级错误，极大的提高了审核效率及准确性。

本申请中，需要按照预设的语法规则对所述目标SQL语句逐条进行语法分析。

步骤S103：若所述目标SQL语句不满足所述预设的语法规则，则报错。

逐条判断所述目标SQL语句是否满足预设的语法规则，若是，则判断下一条所述目标SQL语句，若否，则报错，提示所述目标SQL语句具有语法错误，并报告所述目标SQL语句错误的原因，以方便修改维护。

步骤S104：存储所述不满足预设的语法规则的目标SQL语句。

本申请中，需要将所述不满足预设的语法规则的目标SQL语句以及对应的错误原因进行存储，以方便后续对所述报错的目标SQL语句进行分析修改。

步骤S105：判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错。

判断所有所述目标SQL语句是否都完成了语法分析，若否，则继续进行语法分析，若是，则对所述目标SQL语句进行语义分析。

所述语义分析主要包括：对所述目标SQL语句的逻辑进行分析和对所述目标SQL语句涉及到的对象进行分析。

所述语义分析主要是分析是否存在一些逻辑上的明显的问题，如果存在问题，则报错。

所述语义分析还包括分析一些SQL语句中涉及到的对象是不是存在等问题，如果需要，则连接到线上数据库服务器将对象取回来，对比，然后确定是不是符合规则，不符合则报错。

步骤S106：存储所述不满足预设的语义分析规则的目标SQL语句。

将所述有明显逻辑问题的目标SQL语句和所述涉及到的对象不符合规则的目标SQL语句进行存储。

本申请只需要预先设置好审核需要的各种预设规则，以及审核的算法，即可以按照所述算法及所述各种预设规则执行所述SQL语句的审核过程，无需DBA去和开发人员交流SQL语句的问题及修改情况，提高了审核的效率。

本申请中，还包括：

将所述存储的不满足预设的语法规则的目标SQL语句和所述存储不满足预设的语义分析规则的目标SQL语句以结果集的方式进行显示。

本申请中，还包括：

语义分析完成之后，再在语法语义分析的基础上，做规则过滤检查，这个主要是用来做语句规范化的，因为已经有了语法分析的结果了，这结果中包括了所有这些语句涉及到的信息，那么在此基础上对语句检查是不是符合规则，非常容易，并且扩展性非常好，在检查之后，如果不符合我们定义的规范，则报错并且缓存，这些规范是由我们DBA来定义的，用来规范化SQL语句而做的。这里涉及到的所有错误，都是先针对每条SQL语句，先缓存起来，最后在完成所有的语句之后，通过结果集的方式一起返回。

与上述本申请一种SQL语句审核的方法实施例1所提供的方法相对应，参见图2，本申请还提供了一种SQL语句审核的系统系统实施例1，在本实施例中，该系统包括：

确定单元201，用于确定目标SQL语句。

分析单元202，用于按照预设的语法规则对所述目标SQL语句进行语法分析。

报错单元203，用于若所述目标SQL语句不满足所述预设的语法规则，则报错。

第一存储单元204，用于存储所述不满足预设的语法规则的目标SQL语句。

判断单元205，用于判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错。

第二存储单元206，用于存储所述不满足预设的语义分析规则的目标SQL语句。

本申请中，还包括：

显示单元，用于将所述存储的不满足预设的语法规则的目标SQL语句和所述存储不满足预设的语义分析规则的目标SQL语句以结果集的方式进行显示。

参考图3，示出了本申请一种数据库运维的方法实施例1的流程图，可以包括以下步骤：

步骤S301：确定目标SQL语句。

首先确定待进行审核的数据库中的目标SQL语句，所述目标SQL语句可以包含一条SQL语句，也可以包含多条SQL语句。

步骤S302：对所述目标SQL语句进行审核。

所述对目标SQL语句进行审核的过程与本申请提供的一种SQL语句审核的方法的过程完全相同，此处不再阐述。

步骤S303：判断所述审核是否完成，若是，则按照预设条件判断所述审核是否通过，若是，则存储所述审核通过的目标SQL语句。

判断所述审核是否完成，当所有所述目标SQL语句的审核均完成时，按照预设的的条件，判断所述目标SQL语句的审核是否通过，若是，则存储所述审核通过的目标SQL语句，若所述目标SQL语句的审核没有通过，则将所述审核没有通过的目标SQL语句及其原因以结果集的形式返回。

步骤S304：判断是否需要执行所述审核通过的目标SQL语句，若是，则逐条执行所述审核通过的目标SQL语句。

针对所述审核通过的目标SQL语句，判断是否需要执行所述目标SQL语句，若不需要，则将所述审核没有通过的目标SQL语句及其原因以结果集的形式返回，若需要，则逐条执行所述目标SQL语句。

步骤S305：判断所述审核通过的目标SQL语句的执行是否出错，若是，则判断是否执行force，若是，则继续执行下一条目标SQL语句，直到所有目标SQL语句均执行完毕，若否，则显示结果集。

所述--enable-force，用来指明，在执行过程中，如果某条SQL执行出现错误，就跳过这条语句，继续执行后面的语句，默认为执行中断。

本申请中，在所述逐条执行审核通过的目标SQL语句时，还可以包括：

获取thread_id信息以及每条所述目标SQL语句执行前后的binlog位置信息，以便后续进行备份时使用。

本申请中，需要获取执行过程的开始binlog位置信息和结束binlog位置信息，以及每条所述目标SQL语句执行前后的binlog位置信息，这样在后续进行备份时，可以只备份开始binlog位置信息和结束binlog位置信息之间的执行过程，在后续进行回滚时，可以根据所述当前执行语句的执行前后的binlog位置信息回滚出对应的回滚语句。

参考图4，示出了本申请一种数据库运维的方法实施例2的流程图，还包括：

步骤S401：判断是否需要进行备份，若是，则按照预设的过滤规则过滤所述获取的binlog位置信息，得到当前执行语句的binlog位置信息。

本申请中，在执行所述目标SQL语句过程中，已经获取了所述执行过程中的所有的binlog位置信息，若需要进行备份时，需要按照预设的过滤规则，过滤掉不需要的binlog位置信息，得到当前执行语句的binlog位置信息。

步骤S402：提取所述当前执行语句的binlog位置信息，并解析所述binlog位置信息，得到所述当前执行语句对应的回滚语句。

回滚是一个很重要的部分，迁涉一些风险很大的语句或者在执行错误之后，如何处理的问题，有了这个功能，就可以在秒级内直接回滚，避免出现经济损失。主要实现方式包括两个部分，首先是DML的回滚，因为上面在备份阶段，已经知道了每条语句执行前后对应的binlog位置及thread_id，那么在执行完成之后，针对每条SQL语句，将对应的属于自己的binlog取回来，因为插入、删除、更新操作生成的binlog都包括我们回滚所需要的数据，那么针对插入语句，解析binlog，生成一条DELETE语句；针对删除操作，生成一条插入语句；针对更新语句，生成一条反更新语句，这样就间接的实现了回滚的目的。但针对更新或者删除，通常一条SQL语句有可能影响一行以上的数据，那么生成的回滚语句就是多个，因为一个回滚语句只是针对一行的，因为这里有一个问题需要注意，在执行前必须要将binlog_format修改为row模式，这样才能产生row格式的binlog，从而才可以从中提取到数据生成回滚语句。还包括DDL语句回滚。

步骤S403：判断所述备份是否完成，若否，则继续依次执行过滤、提取、解析的过程以及判断的过程，直到备份完成。

本申请中，所述结果集中的内容包括：上面说了所有的审核结果，都是以MySQL结果集返回的，它包括以下的列：ID(SQL块中单条语句所处的序号)、错误分级(影响执行的语句的等级为2，不影响执行但不符合规则的语句的等级为1，完全没有问题的语句的等级为0)、错误信息(单条语句在审核中出现的所有问题或者错误都存储在这个列中)、当前的SQL语句、影响行数(执行前是预计影响行数，执行后是实际影响行数，这个对我们审核一个语句很重要)、执行序号(这个和上面备份时提到的是一个值，用来在回滚的时候从备份表中找到对应的回滚语句)。

与上述本申请一种数据库运维的方法实施例1所提供的方法相对应，参见图5，本申请还提供了一种数据库运维的系统系统实施例1，在本实施例中，该系统包括：

确定单元501，用于确定目标SQL语句。

审核单元502，用于对所述目标SQL语句进行审核。

第一判断单元503，用于判断所述审核是否完成，若是，则按照预设条件判断所述审核是否通过，若是，则存储所述审核通过的目标SQL语句。

第二判断单元504，用于判断是否需要执行所述审核通过的目标SQL语句，若是，则逐条执行所述审核通过的目标SQL语句。

第三判断单元505，用于判断所述审核通过的目标SQL语句的执行是否出错，若是，则利用force执行所述出错的目标SQL语句，若所述force执行的结果显示所述出错的目标SQL语句为真，则继续执行下一条目标SQL语句，直到所有目标SQL语句均执行完毕，若否，则显示结果集。

本申请中，还包括：

获取单元，用于获取thread_id信息以及每条所述目标SQL语句执行前后的binlog位置信息。

参见图6，本申请还提供了一种数据库运维的系统系统实施例2的结构示意图，在本实施例中，该系统包括：

第四判断单元601，用于判断是否需要进行备份，若是，则按照预设的过滤规则过滤所述获取的binlog位置信息，得到当前执行语句的binlog位置信息。

回滚单元602，用于提取所述当前执行语句的binlog位置信息，并解析所述binlog位置信息，得到所述当前执行语句对应的回滚语句；

第五判断单元603，用于判断所述备份是否完成，若否，则继续依次执行过滤、提取、解析的过程以及判断的过程，直到备份完成。

在具体实现的过程中，通过对MySQL代码的改造，保留原MySQL服务器的一个框架，在这个基础框架上实现了我们上面提出的全新的需求。

本申请中，协议保留原来的格式，只是将原有的安全认证模块移除了，这样这个系统就不需要做多余的工作去支持上层应用的调用了，直接使用MySQL接口就可以完成，同时它已经支持的接口功能比较完善，针对各种语言的协议支持比较完整。开发需要审核时，只需要将需要审核或执行的语句以分号分隔，在最前面以注释的方式写明将要在什么地址审核、执行，同时指定连接数据库的用户名密码，这样本发明所述的系统就可以很智能的一次性指出里面存在的全部问题了。例如：/*--host＝127.0.0.1；--port＝3306；--user＝user；--password＝password；*/sql1；sql2；sql3。

在本发明所述的协议中，已经说到了，在要审核或者执行的语句前面加上注释，来让本发明所述系统知道具体要做什么操作，这其实是给本系统提供了一些外部定义的一些接口，除上面所说的四个选项之外，还包括其它一些选项，具体为：--enable-check，用来指明这只是用来审核的，不需要执行；--enable-execute，用来指明当前的语句块需要先审核再执行；--enable-force，这用来指明，在执行过程中，如果某条SQL执行出现错误，就跳过这条语句，继续执行后面的语句，默认为执行中断；--enable-remote-backup，这个用来指明在执行完成之后，是不是要备份及生成回滚语句，默认是开启的。

审核：包括语法、语义分析、规则过滤这几个阶段。在审核中，我们第一次引入了通过语法分析来实现，并且语法规则和MySQL的语法规则完美兼容，审核的准确度非常高。同时加入一些新的规则，完全杜绝了一些已知的具有很高风险的SQL语句的出现，同时不再会出现一些低级错误，导致DBA还要花额外的时间来处理，极大提高DBA工作效率及准确性。在语法分析完成之后，进入语法分析，语义分析阶段主要是分析是否存在一些逻辑上的明显的问题，如果存在问题，则报错并缓存，还包括一些SQL语句中涉及到的对象是不是存在等问题，如果需要则连接到线上数据库服务器将对象取回来，对比，然后确定是不是符合规则，不符合则报错并缓存。语义分析完成之后，再在语法语义分析的基础上，做规则过滤检查，这个主要是用来做语句规范化的，因为已经有了语法分析的结果了，这结果中包括了所有这些语句涉及到的信息，那么在此基础上对语句检查是不是符合规则，非常容易，并且扩展性非常好，在检查之后，如果不符合我们定义的规范，则报错并且缓存，这些规范是由我们DBA来定义的，用来规范化SQL语句而做的。这里涉及到的所有错误，都是先针对每条SQL语句，先缓存起来，最后在完成所有的语句之后，通过结果集的方式一起返回。

执行：在上面审核通过的基础上，因为所有的SQL语句都被缓存起来了，到执行阶段，依次执行每一条语句，此时当前发明的系统就作为线上数据库的客户端连接到线上数据库，然后执行语句。如果需要备份，则要在执行前取到线上数据库binlog的位置以及当前连接的thread_id，在执行后也取一次线上binlog的位置，这将用于后面的备份于回滚。

备份：实现方式是在本发明所说的系统中配置一个远程备份服务器，在做执行操作并且选择备份的情况下，本系统会自动将本次执行的所有SQL相关的信息备份到远程备份服务器上面，这些信息包括：每条SQL语句，执行前后的binlog位置，操作的数据库，操作的数据库地址，回滚序号(下面回滚部分会用到)等。但线上数据库服务器是多个，备份服务器只有一个，那么他们之间的对应关系是按库对应的，线上的一个库对应的备份服务器中的库名是根据线上库所在地址的IP加上端口再加上库名组成的，所以库之间还是一对一的关系。

回滚：是一个很重要的部分，迁涉一些风险很大的语句或者在执行错误之后，如何处理的问题，有了这个功能，就可以在秒级内直接回滚，避免出现经济损失。主要实现方式包括两个部分，首先是DML的回滚，因为上面在备份阶段，已经知道了每条语句执行前后对应的binlog位置及thread_id，那么在执行完成之后，针对每条SQL语句，将对应的属于自己的binlog取回来，因为插入、删除、更新操作生成的binlog都包括我们回滚所需要的数据，那么针对插入语句，解析binlog，生成一条DELETE语句；针对删除操作，生成一条插入语句；针对更新语句，生成一条反更新语句，这样就间接的实现了回滚的目的。但针对更新或者删除，通常一条SQL语句有可能影响一行以上的数据，那么生成的回滚语句就是多个，因为一个回滚语句只是针对一行的，因为这里有一个问题需要注意，在执行前必须要将binlog_format修改为row模式，这样才能产生row格式的binlog，从而才可以从中提取到数据生成回滚语句。

返回方式：审核或者执行过程中有什么问题，特别是审核部分，有什么错误必须要报出来，才能让开发进一步修改，符合规范，那么这里需要一个很友好的，易处理的方式来解决这个问题。本发明第一次提出来以结果集方式将审核结果报出来的，使用这种方案的好处有很多，包括：已经有很多成熟的MySQL接口可以方便处理MySQL结果集，所以不需要本系统再做额外的工作去支持结果集的处理；可以容纳更多的内容，之前的很多审核系统，每次审核只能返回一个错误，很不友好，而本发明可以一次性将所有不符合规范的问题以结果集的方式返回，这样就可以做到一目了然，心中有数，进而可以一次性将所有问题修改好，极大提高工作效率。

在线改表：在MySQL系统中，对大表的DDL操作对数据库的影响是很大的，一般需要锁表，表越大，锁的时间越长，在这段时间内，整个表都不能被访问了。所以很多人都对这个进行优化，在本发明中，为了能全自动的运维执行线上操作，我们也在这方面做了相应的工作，主要是实现方式是先创建一个将目标表结构修改之后的结构的swap表，然后再创建三个触发器，分别是增删改三种事件的触发器，它们的动作分别是：当插入新数据时，就将新的数据也往swap表中插入一份，当更新数据时，也更新一次swap表的相应的数据，如果不存在就忽略，当删除数据时，就同时在swap表中执行一次同样的删除，有了这三个触发器，就可以将数据一部分一部分的从原表向swap表中搬运了，因为这三个触发器可以保证在改表期间，所有对旧表的修改都会反映到swap上面，那么当搬完之后，将这两个表的名字互换一下，就完成了整个修改表的操作，而只有这个互换名字的时候才需要很短暂的锁一下表，之后做些清理操作，比如删除旧表、触发器等，这样就完成了在线改表操作，不会再出现长时间锁表的情况。

具体的执行过程为：首先从一开始，提交给本系统的语句就是多个，而不是一个语句，所以需要在不同阶段，对所有的语句都处理一遍。在审核阶段，对每个语句，进行语法语义分析，将有问题的都存起来，如果不执行，就直接返回结果集，这些错误都可以一次性的反馈回去。进入执行阶段之后，本系统会做为一个客户端，连接到线上去执行，但在执行前与执行后，都要取一下当前连接的binlog位置及thread_id，主要是为了后面生成回滚语句时做过滤用的。执行过程中，如果出错了，则需要使用到上面提到的--enable-force选项，如果为真，则跳过这一条，执行下一条，依次执行，直到完成之后，此时需要判断是不是设置了备份，如果没有则直接将当前执行结果以结果集的方式返回，如果需要备份，就进入备份阶段，根据上面获取到的binlog位置及thread_id，将从线上获取的binlog做过滤，取到属于当前语句产生的Binlog，然后根据其中的数据，反过来拼出对应的回滚语句。然后备份完成之后，此时就算整个操作都完成了，那么此时再以结果集的方式将整个过程都返回。

支持的协议是MySQL原生协议，这方便在本系统上层进一步开发审核流程的平台等系统。

在本系统执行语法分析之后，做语义分析时，需要用到什么数据库对象，则需要连接到线上数据库服务器，通过简单的show命令，将对象结构取回来在本地对比。

在执行阶段，执行前后取binlog位置，thread_id需要连接到线上取回来，执行操作本身也是通过连接到线上直接通过MySQL接口来执行对应的SQL语句。

在备份阶段，需要根据前面获取到的binlog位置及thread_id来获取binlog，这个操作是需要从线上服务器获取，此时本系统的角色相当于线上服务器的一个从库。

所有的操作都可以在秒级内回滚，在执行完成之后，直接就生成了被执行SQL语句的回滚语句，如果需要回滚，则直接拿出来执行即可。

所述回滚包括DML语句的回滚及DDL语句的回滚。

所有的审核、执行、备份等操作完成之后，返回信息都是以结果集的方式返回，在其中出现任何错误或者问题，都可以一次性的全部返回，一目了然，极大提高工作效率。

支持在线改表操作，本系统可以直接对线上的大表执行不锁表的修改操作，从而避免一些故障的产生，或者从此之后，改表操作再也不需要到半夜去做了。

综上，本申请提供的一种SQL语句审核的方法、数据库运维的方法及系统，能够有效的进行SQL语句的审核以及提高数据运维的效率。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

以上对本申请所提供的一种SQL语句审核的方法、数据库运维的方法及系统进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种SQL语句审核的方法，其特征在于，该方法包括：

确定目标SQL语句；

按照预设的语法规则对所述目标SQL语句进行语法分析；

若所述目标SQL语句不满足所述预设的语法规则，则报错；

存储所述不满足预设的语法规则的目标SQL语句；

判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错；

存储所述不满足预设的语义分析规则的目标SQL语句。

2.根据权利要求1所述的方法，其特征在于，还包括：

将所述存储的不满足预设的语法规则的目标SQL语句和所述存储不满足预设的语义分析规则的目标SQL语句以结果集的方式进行显示。

3.一种SQL语句审核的系统，其特征在于，该系统包括：

确定单元，用于确定目标SQL语句；

分析单元，用于按照预设的语法规则对所述目标SQL语句进行语法分析；

报错单元，用于若所述目标SQL语句不满足所述预设的语法规则，则报错；

第一存储单元，用于存储所述不满足预设的语法规则的目标SQL语句；

判断单元，用于判断所述语法分析是否完成，若是，则对所述目标SQL语句进行语义分析，若所述目标SQL语句不满足预设的语义分析规则，则报错；

第二存储单元，用于存储所述不满足预设的语义分析规则的目标SQL语句。

4.根据权利要求3所述的系统，其特征在于，还包括：

显示单元，用于将所述存储的不满足预设的语法规则的目标SQL语句和所述存储不满足预设的语义分析规则的目标SQL语句以结果集的方式进行显示。

5.一种数据库运维的方法，其特征在于，该方法包括：

确定目标SQL语句；

对所述目标SQL语句进行审核；

判断所述审核是否完成，若是，则按照预设条件判断所述审核是否通过，若是，则存储所述审核通过的目标SQL语句；

判断是否需要执行所述审核通过的目标SQL语句，若是，则逐条执行所述审核通过的目标SQL语句；

判断所述审核通过的目标SQL语句的执行是否出错，若是，则判断是否执行force，若是，则继续执行下一条目标SQL语句，直到所有目标SQL语句均执行完毕，若否，则显示结果集。

6.根据权利要求5所述的方法，其特征在于，在所述逐条执行审核通过的目标SQL语句时，还包括：

获取thread_id信息以及每条所述目标SQL语句执行前后的binlog位置信息。

7.根据权利要求5或6所述的方法，其特征在于，还包括：

判断是否需要进行备份，若是，则按照预设的过滤规则过滤所述获取的binlog位置信息，得到当前执行语句的binlog位置信息；

提取所述当前执行语句的binlog位置信息，并解析所述binlog位置信息，得到所述当前执行语句对应的回滚语句；

判断所述备份是否完成，若否，则继续依次执行过滤、提取、解析的过程以及判断的过程，直到备份完成。

8.一种数据库运维的系统，其特征在于，该系统包括：

确定单元，用于确定目标SQL语句；

审核单元，用于对所述目标SQL语句进行审核；

第一判断单元，用于判断所述审核是否完成，若是，则按照预设条件判断所述审核是否通过，若是，则存储所述审核通过的目标SQL语句；

第二判断单元，用于判断是否需要执行所述审核通过的目标SQL语句，若是，则逐条执行所述审核通过的目标SQL语句；

第三判断单元，用于判断所述审核通过的目标SQL语句的执行是否出错，若是，则判断是否执行force，若是，则继续执行下一条目标SQL语句，直到所有目标SQL语句均执行完毕，若否，则显示结果集。

9.根据权利要求8所述的系统，其特征在于，还包括：

获取单元，用于获取thread_id信息以及每条所述目标SQL语句执行前后的binlog位置信息。

10.根据权利要求8所述的系统，其特征在于，还包括：

第四判断单元，用于判断是否需要进行备份，若是，则按照预设的过滤规则过滤所述获取的binlog位置信息，得到当前执行语句的binlog位置信息；

回滚单元，用于提取所述当前执行语句的binlog位置信息，并解析所述binlog位置信息，得到所述当前执行语句对应的回滚语句；

第五判断单元，用于判断所述备份是否完成，若否，则继续依次执行过滤、提取、解析的过程以及判断的过程，直到备份完成。