CN103514166A - Sql检查方法与装置 - Google Patents

Abstract

本申请提供了一种SQL检查方法与装置，其中，SQL检查方法包括：根据文件变更类型，获取待检查文件，所述待检查文件为进行过SQL修改的文件；对所述待检查文件进行SQL修改过滤，获取待检查的SQL修改；将所述待检查的SQL修改转换为SQL语句；获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查。通过本申请，实现了SQL REVIEW对变化了的SQL进行有效的检查，减轻了DBA负担，节约了SQL REVIEW成本。

Description

SQL检查方法与装置

技术领域

本申请涉及计算机技术领域，特别是涉及一种SQL（Structured QueryLanguage，结构化查询语言）检查方法与装置。

背景技术

目前随着计算机技术应用的越来越广泛，很多企业的工作和运营都需要计算机进行，企业的发展也在一定程度上依赖于计算机技术的发展。对于这些企业来说，随着业务的高速发展，企业的应用系统也逐渐庞大，并且伴随着业务及架构上的大量改造工作，会不断地有项目上线，甚至每周都会有大量的项目上线。通常情况下，这些项目会通过SVN（subversion）进行版本管理。SVN是近年来崛起的版本管理工具，版本管理是软件配置管理的基础，它管理并保护开发者的软件资源，它的主要功能有：1、集中管理档案，安全授权机制；2、软件版本升级管理；3、加锁功能，即在文件更新时保护文件，避免不同的用户更改同一文件时发生冲突；4、提供不同版本源程序的比较。

以每周上线的项目在50个以上为例，由于当前的项目通过SVN来实现版本控制，需要修改的系统都会在项目中有一个SVN分支，因此，每个项目平均会有多个分支。当这些分支有变化时，需要由DBA（数据库管理员）通过SQL REVIEW将这些变化找出来进行审查。SQL REVIEW是DBA对于开发人员书写的SQL的一种检查机制，这是保证系统稳定性非常重要的一个因素。为了确保线上环境数据库能够良好稳定地运行，DBA会在开发人员书写的SQL语句发布到线上之前进行一次检查，找出有问题的SQL，并提出修改意见和建议，或者DBA直接对SQL进行优化性能后，再提交到生产环境，防止因SQL性能等问题引起的系统问题。

DBA进行SQL REVIEW的第一步，就是要从这些应用系统中把变更的SQL文件都找出来。据统计，每个项目平均有7-8个分支。因此，DBA每周需要比较大约350-400个SVN的分支，并找出变更的SQLMAP文件，这是很大的一部分工作量。按每个分支的版本比较大约1分钟来计算，一周共需要6个小时的人力成本。在找出有变化的SQL文件后，还需要手工的进行SQL比较，去掉SQL中所有动态的条件，替换所有的绑定变量，并且打开对应的数据库，去手工的查看每个SQL的执行计划，最后需要人为的来判断SQL的结果。这些步骤是SQL REVIEW过程中最繁琐的，也是最重要的一部分。这一块工作，相对于查找文件来讲，更加耗时。因此，SQL REVIEW成为DBA工作中最耗时及最花费精力的一部分。

现有的技术方案中，在小公司中，都是人工的进行SQL REVIEW或者由于业务量小，根本不进行SQL REVIEW。在大公司中，也有一些工具，但是受限于技术方案上的实现方式及技术难度，不能有效地实现SQLREVIEW，从而无法对变化了的SQL进行有效的检查，也无法减轻DBA负担，节约SQL REVIEW成本。

发明内容

本申请所要解决的技术问题是提供一种SQL检查方法与装置，以解决现有SQL REVIEW无法对变化了的SQL进行有效的检查，无法减轻DBA负担，节约SQL REVIEW成本的问题。

为了解决上述问题，本申请公开了一种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语句，以顺利地进行数据库连接的SQL执行计划获取，实现对SQL执行计划的检查，整个过程无须人工干预。通过上述操作，本申请将传统的SQL REVIEW工作，通过系统调用操作管理命令实现了自动化，DBA只需要运行程序，就可以轻松地完成SQL REVIEW，解决了现有SQL REVIEW无法对变化了的SQL进行有效的检查，无法减轻DBA负担，节约SQL REVIEW成本的问题。

附图说明

图1是根据本申请实施例一的一种SQL检查方法的步骤流程图；

图2是根据本申请实施例二的一种SQL检查方法的步骤流程图；

图3是根据本申请实施例三的一种SQL检查方法的步骤流程图；

图4是图3所示实施例中每一个SQLMAP文件的处理流程图；

图5是图3所示实施例中对SQL执行计划进行检查的步骤流程图；

图6是根据本申请实施例四的一种SQL检查装置的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

实施例一

参照图1，示出了根据本申请实施例一的一种SQL检查方法的步骤流程图。

本实施例的SQL检查方法包括以下步骤：

步骤S102：根据文件变更类型，获取待检查文件。

文件变更类型是指开发人员对文件作了何种类型的SQL变更，如：修改、新增、删除等，相对应地，进行了变更后的文件类型可以是修改文件、新增文件、删除文件等。

所述待检查文件为进行过SQL修改的文件，进行过SQL修改的文件为修改类型的文件，即，在原文件基础上又进行了SQL修改的文件。当然，新的SQL文件，即增加类型的SQL文件也可以被认为是待检查文件。

步骤S104：对待检查文件进行SQL修改过滤，获取待检查的SQL修改。

为了准确获取本次待检查的SQL修改，需要对待检查文件进行SQL修改过滤，将其它的SQL修改清除。在清除时，可以通过相应的升级包标识或数据包标识等能够标识本次SQL修改的标志，将不属于本次修改的SQL修改清除。

以SVN的rebase（合并）为例，在基于SVN的项目开发过程中，一个系统通常会被多个流所修改，并且多个流同时提交的情况下，需要做rebase（即合并），先将代码下载到其中一个流中，进行合并，合并完成后，将最新的代码再次提交到主干上，这样，所有的流都能拥有这个系统最新的代码。但是，流中也会产生许多不属于自己流的变更（变更有可能是通过rebase加进来的），这样经常会对SQL REVIEW造成干拢。在进行SQL检查时，需要将这些rebase清除。

步骤S106：将待检查的SQL修改转换为SQL语句。

通过本步骤，实现了修改的SQL语句的自动提取和格式转换。优选地，可以通过正则表达式，如Perl的正则表达式功能，实现SQL语句的自动提取和格式转换。例如，转换前有很多IBATIS标签，很多动态的条件，数据库无法识别的SQL语句，在转换后，数据库可以识别出相应的SQL。在实际的转换过程中，具体的转换处理对每条SQL都不一样，需要由本领域技术人员根据实际情况，对待转换处理的SQL进行相关的多字符串处理操作。当然，不限于此，在实际使用中，本领域技术人员还可以采用其它适当方式实现SQL语句的自动提取和格式转换。

步骤S108：获取SQL语句对应的SQL执行计划，对SQL执行计划进行检查。

通过SQL语句的相关信息，可以连接到相应的数据库中，获取SQL语句对应的SQL执行计划，进而对SQL执行计划进行检查。

SQL执行计划是指数据库对SQL执行有很多种方案可以选择，如是否使用索引等，它所选择的方案的就叫执行计划。这里的选择方案在SQL正式执行之前产生，所以，DBA可以通过SQL执行计划来判断SQL性能的好坏。

通过本实施例，在一次SQL检查中，根据文件变更类型，确定进行过SQL修改的文件；进而将该文件中除本次检查的SQL修改外的其它SQL修改清除，以清楚地获取本次所需要检查的SQL，保证待检查的SQL修改的准确性；然后，自动提取SQL修改的信息，将SQL修改自动转换为标准的SQL语句，以顺利地进行数据库连接的SQL执行计划获取，实现对SQL执行计划的检查，整个过程无须人工干预。通过上述操作，本实施例将传统的SQL REVIEW工作，通过系统调用操作管理命令实现了自动化，DBA只需要运行程序，就可以轻松地完成SQL REVIEW，解决了现有SQL REVIEW无法对变化了的SQL进行有效的检查，无法减轻DBA负担，节约SQLREVIEW成本的问题。

实施例二

参照图2，示出了根据本申请实施例二的一种SQL检查方法的步骤流程图。

本实施例的SQL检查基于版本管理工具SVN以及IBATIS框架。其中，IBATIS框架是apache的一个开源项目，它是一个基于Java的持久层框架。IBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），是一种“半自动化”的ORM（对象关系映射）实现。但本领域技术人员应当明了，使用类似架构及工具的系统均可参照本实施例进行SQL检查。

本实施例的SQL检查方法包括以下步骤：

步骤S202：检查进行过SQL修改的文件中是否存在无效修改的文件，若是，则不对无效修改的文件进行SQL检查；若否，则执行步骤S204。

项目中的SVN分支，可能有效，也有可能无效（即没有有效的变更）。在页面查看项目时，首先会将无效的SVN分支进行过滤，不对其进行SQL检查。

步骤S204：调用SVN命令，使SVN命令根据文件变更类型，获取修改类型的待检查文件。

SVN中，存在可以根据文件变更类型（如增加类型，删除类型，修改类型等），获取修改类型的待检查文件的命令。本实施例中，系统通过调用这些命令，获取相应的待检查文件。

步骤S206：获取待检查文件的当前版本的信息和当前版本的前次版本的信息。

在进行了无效SVN分支过滤后，待检查的文件将都是进行了有效SQL修改的文件。针对获得的进行了有效SQL修改的待检查文件，再判断是否存在rebase的信息，该信息以SVN日志的形式存放在SVN服务器上。如果发现有rebase，则将rebase版本过滤，这个过滤的操作，会涉及到两次比较，即从原来的一次比较，分开两次进行（rebase前一次，rebase后一次），这样初步操作的结果，可以排除无效SVN，及rebase对结果的干扰。这是因为由rebase的版本信息，可能会比较出不需要的信息，所以需要将rebase剔除再进行比较。例如，版本包括（1，3，5，rebase，7，9），中间有rebase，如果直接比较版本9-版本1会有问题，需要作版本5-版本1和版本9-版本7两次单独比较，这样就可以剔除rebase进来的信息。其中，rebase是指并两个分支的代码，合并到同一个主干上。（如两个分支（a,b）修改了同一个文件，那么合并后，在a分支上会有b分支的内容，所以需要将rebase去除）

步骤S208：根据当前版本的信息和当前版本的前次版本的信息，获取当前版本对应的待检查文件的文件内容，和当前版本的前次版本对应的待检查文件的文件内容。

其中，版本的信息也即SVN的版本号，其存储于SVN的日志中。

步骤S210：将当前版本的前次版本对应的待检查文件的文件内容中的SQL内容从当前版本对应的待检查文件的文件内容中清除，获取待检查的SQL修改。

优选地，可以分别对当前版本对应的待检查文件的文件内容，和当前版本的前次版本对应的待检查文件的文件内容进行解析，并分别生成对应的SQL标识和SQL内容；将SQL内容分别存放到不同的Hash（哈希）结构中；进而根据SQL标识比较不同的Hash结构中的SQL内容，获取待检查的SQL修改。

在真实的SQL REVIEW过程中，所有的SQLMAP文件（包括应用系统相关的所有SQL语句）会存在增加，删除，修改三种类型：（1）对于增加类型的SQLMAP文件，获取它的最后一个版本即可；（2）对于删除类型的SQLMAP文件，不需要进行处理，只要告诉使用者，这个文件已经删除，并展示删除的内容，即获取它最初版本的信息；（3）需要特殊处理的是修改类型的SQLMAP文件，首先是日志展示，直接用SVN现有的命令获取它们的差异版本信息即可，但是真实的SQL语句并不能获取到。这时，这里需要进行特殊地处理，即，根据差异比较两个SQL文件版本，并分别获取这两个版本的文件内容；然后将文件内容进行解析，解析成sqlid（SQL标识），sqltext（SQL内容）两部分，并分别存放到hash结构中，如perl中的两个hash结构hash_pre，hash_after中；最后，比较hash_pre，hash_after，找出有变动的SQL语句。

步骤S212：使用正则表达式，将待检查的SQL修改格式化为SQL语句。

需要说明的是，将SQL修改格式化为SQL语句不限于使用正则表达式的形式，本领域技术人员也可以采用其它适当方式。但使用正则表达式方式，实现方便、灵活，且实现成本低。

当基于IBATIS框架时，可以使用正则表达式，先将待检查的SQL修改中的IBATIS标记删除，然后将删除了IBATIS标记的SQL修改格式化为SQL语句。

本实施例中，会根据比较得到的SQL去获取对应的执行计划，由于SQL都是基于IBATIS框架，因此，SQL会有许多动态的条件，因而不能直接拿来使用。为此，本实施例使用了正则表达式功能（如PERL强大的正则表达式功能）进行了处理，将SQL修改中的IBATIS标记删除，然后将格式化为最终数据库能够识别的SQL。

步骤S214：使用正则表达式，从待检查的SQL修改的信息中获取待检查的SQL修改所在的数据表名；获取数据表名所在的数据库信息；连接数据库信息指示的数据库，从数据库中获取SQL语句对应的SQL执行计划。

仅将SQL修改格式化为标准的SQL语句还不够，还需要使用正则表达式（如强大的PERL）来解析出它的表名，根据表名，去一个预设的统计数据表中进行查找，获取它的数据库服务器信息。然后，建立数据库连接，获取SQL语句对应的执行计划。

优选地，在获取数据表名所在的数据库信息时，可以通过数据库对应关系表确定数据表名对应的数据库，获取数据库的信息，其中，数据库对应关系表用于指示数据表与数据库的对应关系，数据库对应关系表中存储有数据库的地址信息。

当然，不限于此，在实际使用中，本领域技术人员还可以采用任意其它适当方式实现SQL执行计划的获取，如通过其它形式（如通过文件或数据库表等）获取数据库信息并进行连接，进而获取SQL执行计划等。

步骤S216：对SQL执行计划进行检查。

SQL的执行计划，有好有坏。本实施例的设计按照交通规则中的，红灯停，绿灯行，黄灯缓行，使用红，黄，绿三种颜色来展示最终的结果。红色表示：这个SQL有严重的性能问题；黄色表示：这条SQL要停下来看看，可能存在性能问题，也可能没有问题；绿色表示：这条SQL肯定没有性能问题。将执行计划的结果按关键字，进行展示。此外，这里的设计中还可以弱依赖于白名单表，如果解析出来的表名在白名单中，就展为绿色，表明这个SQL肯定没有问题。

步骤S218：使用WEB网页方式展示SQL检查的结果。

使用WEB网页方式展示SQL检查结果，更加方便、直观，便于DBA操作。但不限于此，在实际应用中，本领域技术人员可以采用任意其它适当方式显示SQL检查结果。

现有的技术方案中，大部分没有工具，靠手工来进行SQL性能的判断，而在已有的一些工具中，也只能进行一些简单的辅助工作，无法进行智能结果判断。（1）现有方案中，因为技术实现方案上的不同，sql review中需要进行review的sql，都是提前定时任务收集的，对于实时进行修改的SQL不能实时的获取到；而本实施例通过调用SVN命令，使所有的SQL都能准确实时的通过SVN命令进行获取，保证了修改后的结果能够立刻获取到。（2）现有方案中，因为SQL解析的难度，仅仅获取到了SQL，对于获取的SQL不能进行格式化或者不能够自动的进行数据库的定位，需要人工来进行数据库的选择；而本实施例使用正则表达式功能，可以方便地进行SQL语句的格式化，并进行SQL表名的解析；此外，因为收集了表和数据库的对应关系，根据表名，可以找出对应的数据库，从而自动连接SQL对应的数据库获取执行计划。（3）现有方案中，因为现有的SVN不能很好的处理修改类型的SQL，所以，现有工具对于修改类型的SQL，无法很准确的抓取到SQL，并且进行直观展示；而本实施例的方案因为对于修改类型的SQL进行了前后版本的2次获取，并准确确定所需解析的版本，利用HASH结构来保存两个文件，所以能够准确地抓取到SQL；并且，对于修改类型的文件，能够有一种非常好的展现方式（WEB方式）来进行结果的展示。（4）现有方案中，因为对于SQL执行计划的结果，无法进一步的处理，所以使用者在查看执行计划时，会比较辛苦，并且很容易出错；而本实施例通过使用积累了很多实验使用中的SQL REVIEW经验，结合实践的经验，对于SQL REVIEW的结果，进行了智能的判断，性能的好坏通过绿，黄，红的三种颜色来展现；同时，因为收集了表的白名单的信息，可以利用白名单，将白名单中的表直接进行过滤，极大地提高了SQL REVIEW的用户体验及准确性。

实施例三

参照图3，示出了根据本申请实施例三的一种SQL检查方法的步骤流程图。

本实施例的SQL检查基于版本管理工具SVN以及IBATIS框架，利用Perl语言来调用操作系统中的SVN命令，并获取项目的SVN分支信息，根据SVN的分支信息，获取所有文件的信息，处理文件，进行REVIEW，并打印执行计划，对执行计划进行智能的判断。需要说明的是，本实施例的语言、框架及工具仅为示例性说明，使用类似语言、框架及工具的系统均可参照本实施例进行SQL检查。

本实施例的SQL检查方法包括以下步骤：

步骤S302：搜索SVN项目。

本实施例中，使用Perl语言，通过Perl CGI（Common Gate Intergace）程序，调用操作系统中的SVN命令进行SVN项目的搜索。Perl语言最重要的特性是它内部集成了正则表达式的功能，不需要编译器和链接器来运行代码。

步骤S304：找出每个项目中对应的所有SVN地址。

步骤S306：获取项目中的SVN分支。

步骤S308：判断是否有未查看的SVN分支，若是，则执行步骤S310；若否，则该项目SQL REVIEW完成。

通过判断是否有未查看的SVN分支，可以实现一个项目中SVN分支的遍历，进而实现一个项目的SQL REVIEW。

步骤S310：进行SVN分支比较。

通过对SVN分支进行比较，可以找出有修改的SQLMAP文件，进行SQL修改的检查。

步骤S312：判断是否有改变的SQLMAP文件，若是，则执行步骤S314；若否，则返回步骤S306。

步骤S314：获取改变的SQLMAP文件。

步骤S316：判断是否有未查看的SQLMAP文件，若是，则执行步骤S318；若否，则返回步骤S306。

步骤S318：格式化SQLMAP文件。

对于一个未查看的SQLMAP文件，对其进行格式化，可以获取该文件中对应于SQL修改的SQL语句。

步骤S320：获取SQL语句。

步骤S322：解析SQL表名。

本实施例中，使用Perl解析SQL表名。

步骤S324：根据SQL表名，找出对应的数据库，判断是否找到对应的数据库，若是，则执行步骤S326；若否，则提示找不到对应数据库信息。

SQL REVIEW中表对应的数据库信息获取，依赖于事前的统计，系统中会定期收集表与schema（数据库IP）的对应关系，这样保证SQL能够正确的连接到准确的数据库上，保留这份信息的表（数据库对应关系表）可以如下所示：

其中，数据库IP指示了该数据库的地址，如在哪台机器上，在该机器上的具体位置等。

根据SQL解析得到的表名，还能直接在页面上查看对应的表结构及索引，当某些时候需要人为进行确认时，可以很方便的进行表结构的查看，减少了连接数据库查看表结构的繁琐工作。

步骤S326：连接相应的数据库查看SQL执行计划。

执行计划是对一个查询任务做出一份怎样去完成任务的详细方案，可以对一个执行计划如SQL执行计划进行判断，以确定一个SQL性能的好差，SQL执行计划可以以字符串形式存放在数据库中。

步骤S328：进行SQL执行计划的智能判断。

智能判断可以弱依赖于一个白名单表，只要SQL语句访问的表在白名单中，即可以直接判断SQL性能很好，可以认为直接拿到绿卡。但白名单表不是必需的，白名单表只是为了让SQL REVIEW提供更加智能的判断，另外白名单表会进行定期的维护。

在进行了SQL执行计划智能判断后，系统会向DBA出具SQL REVIEW日志，以告知DBA相关信息。

步骤S330：判断是否有未查看的SQL，若是，则返回步骤S320；若否，则返回步骤S314。

在上述过程中，一个项目中可能有多个SVN分支，同时一个SVN分支中可能存在多个SQLMAP文件，一个SQLMAP文件中又可能存在多条SQL语句。因此，程序需要遍历项目中的所有SQL语句，对每条SQL抓取执行计划，分析后输出结果。

其中，对于每一个SQLMAP文件的处理如图4所示，包括：

步骤S402：获取SQLMAP文件。

步骤S404：判断文件的修改类型，若为删除类型，则执行步骤S406；若为增加类型，则执行步骤S408；若为修改类型，则执行步骤S412。

步骤S406：获取最初未删除的版本，进行显示，结束本SQLMAP文件处理流程。

步骤S408：获取最终的版本。

步骤S410：进行SQL提取和处理，结束本SQLMAP文件处理流程。

步骤S412：获取最初的版本a和最终版本号b。

步骤S414：将a提取到hash结构hash_a，b提取到hash_b。

步骤S416：根据SQL的唯一标识SQL_ID，计算hash_b—hash_a。

步骤S418：将相减的结果进行处理，结束本SQLMAP文件处理流程。

也就是说，程序会根据SQLMAP文件的三种状态，进行后继处理的判断：（1）对于增加类型的SQLMAP文件，获取它的最后一个版本，解析文件获取SQL语句。（2）对于删除类型的SQLMAP文件，不需要进行处理，只要告诉使用者，这个文件已经删除，并展示删除的内容，即获取它最初版本的信息。（3）对于修改类型的文件，则通过一种巧妙的方式，根据IBATIS框架中SQL的特点，将它们存储到两个HASH数据结构中，进行比较。如图4中所示，将SQL存放到两个哈希数据结构中之后，根据hash_b中的每个键值（sql_id），去比较对应的hash_a中的键值(sql_id)，若sql_id不存在，表示这条SQL语句是新增加的，若键值存在，并且value不同，表示这条SQL进行了修改，否则，说明这条sql_id对应的SQL语句没有进行修改。

在获取了SQL语句后，需要连接数据库，获取相应的SQL执行计划，对SQL执行计划进行检查，一种对SQL执行计划进行检查的流程如图5所示，包括：

步骤S502：解析SQL获取表名。

步骤S504：判断表名是否属于白名单，若是，则显示为绿色，表示SQL的性能很好；若否，则执行步骤S506。

步骤S506：连接数据库获取执行计划。

步骤S508：判断是否为insert，若是，则显示为绿色，表示SQL的性能很好；若否，则执行步骤S510。

步骤S510：判断是否为unique scan/不带buffer sort的range scan等，若是，则显示为绿色，表示SQL的性能很好；若否，则执行步骤S512。

步骤S512：判断是否为full scan/skip scan等，若是，则显示为红色，一般表示存在严重的性能问题，需要重点关注；若否，则执行步骤S514。

步骤S514：判断是否带有buffer sort，range scan等，若是，则显示为黄色，表示可能存在性能问题，需要确认；若否，则显示为绿色，表示性能良好。

上述过程中，“insert”、“unique scan”、“buffer sort”、“range scan”、“fullscan”、“skip scan”等均为系统参数，当“insert”、“unique scan”、“buffer sort”、“range scan”显示为绿色时，表示性能良好，而对于“full scan”和“skip scan”，其显示为红色时，表示需要重点关注。

从图5中可以看出，SQL执行计划检查中显示的颜色共有三种，其中：绿色，表示SQL肯定没有问题，可以直接通过。如在白名单中的表，或者index unique scan的执行计划；红色，表示SQL可能存在严重的性能问题，需要重点进行查看，一般来说是全表扫描的表，或者buffer sort，index skipscan，fast full scan等；黄色，表示可能存在性能问题，需要进行确认，一般来说是index range scan等。此外，智能判断可以弱依赖于一个白名单表，只要SQL语句访问的表在白名单中，即可以直接判断SQL性能很好，可以认为直接拿到绿卡。但白名单表不是必需的，白名单表只是为了让SQLREVIEW提供更加智能的判断，另外白名单表会进行定期的维护。

通过本实施例，使用Perl CGI来实现SQL检查，能够很好地进行数据库及操作系统之间的交互，并且Perl拥有非常强大的正则表达式处理功能，及文本处理功能，可以达到最佳效果，且对硬件没有特殊要求。通过使用强大的PERL正则表达式及CGI程序的优点，因为Perl CGI程序，能够实时的调用任意的操作系统shell命令，所以所有的SQL都能准确实时的通过SVN命令进行获取，保证修改后的结果能够立刻获取到；因为使用了PERL的强大正则表达式功能，可以方便的进行SQL语句的格式化，并进行SQL表名的解析，因为收集了表和数据库的对应关系，根据表名，可以找出对应的数据库，从而自动连接SQL对应的数据库获取执行计划；因为对于修改类型的SQL进行了前后版本的2次获取，并准确解析的，利用HASH结构来保存两个文件，所以对于修改类型的文件，能够有一种非常好的展现方式来进行结果的展示；因为积累了很多实验使用中的SQLREVIEW经验，结合实践的经验，对于SQL REVIEW的结果，进行了智能的判断，性能的好坏通过绿，黄，红的三种颜色来展现。同时，因为收集了表的白名单的信息，可以利用白名单，将白名单中的表直接进行过滤。极大的提高了SQLREVIEW的用户体验及准确性；此外，因为脚本使用linux shell，来实时的调用SVN相关的命令，所以，后有页面展示的执行计划信息，都是实时的，保证结果能够实时的展示出来。

实施例四

参照图6，示出了根据本申请实施例四的一种SQL检查装置的结构框图。

本实施例的SQL检查装置包括：获取模块602，用于根据文件变更类型，获取待检查文件，所述待检查文件为进行过SQL修改的文件；修改清除模块604，用于对待检查文件进行SQL修改过滤，获取待检查的SQL修改；转换模块606，用于将待检查的SQL修改转换为SQL语句；检查模块608，用于获取SQL语句对应的SQL执行计划，对SQL执行计划进行检查。

优选地，获取模块602，用于使用Perl语言调用版本管理工具SVN命令，使SVN命令根据文件变更类型，获取修改类型的待检查文件。

优选地，修改清除模块604包括：版本信息获取模块6042，用于获取待检查文件的当前版本的信息和当前版本的前次版本的信息；版本内容获取模块6044，用于根据当前版本的信息和当前版本的前次版本的信息，获取当前版本对应的待检查文件的文件内容，和当前版本的前次版本对应的待检查文件的文件内容；比较清除模块6046，用于将当前版本的前次版本对应的待检查文件的文件内容中的SQL内容从当前版本对应的待检查文件的文件内容中清除，获取待检查的SQL修改。

优选地，比较清除模块6046包括：解析模块60462，用于分别对当前版本对应的待检查文件的文件内容，和当前版本的前次版本对应的待检查文件的文件内容进行解析，并分别生成对应的SQL标识和SQL内容；存储模块60464，用于将SQL内容分别存放到不同的哈希Hash结构中；比较模块60466，用于根据SQL标识比较不同的Hash结构中的SQL内容，获取待检查的SQL修改。

优选地，转换模块606将待检查的SQL修改转换为SQL语句时，使用正则表达式，将待检查的SQL修改格式化为SQL语句。

优选地，转换模块606使用正则表达式，将待检查的SQL修改格式化为SQL语句时，使用正则表达式，将待检查的SQL修改中的IBATIS标记删除，将删除了IBATIS标记的SQL修改格式化为SQL语句。

优选地，检查模块608在获取SQL语句对应的SQL执行计划时，使用正则表达式，从待检查的SQL修改的信息中获取待检查的SQL修改所在的数据表名；获取数据表名所在的数据库信息；连接数据库信息指示的数据库，从数据库中获取SQL语句对应的SQL执行计划。

优选地，检查模块608在获取数据表名所在的数据库信息时，通过数据库对应关系表确定数据表名对应的数据库，获取数据库的信息，其中，数据库对应关系表用于指示数据表与数据库的对应关系，数据库对应关系表中还存储有数据库的地址信息。

优选地，检查模块608，用于使用正则表达式，从待检查的SQL修改的信息中获取待检查的SQL修改所在的数据表名；判断数据表名是否在系统的白名单表中，白名单表中包括设定的指示SQL语句检查通过的数据表名；若数据表名在白名单表中，则确定SQL语句通过检查。

优选地，本实施例的SQL检查装置还包括：过滤模块610，用于在获取模块602根据文件变更类型，获取待检查文件之前，检查进行过SQL修改的文件中是否存在无效修改的文件；若是，则不对无效修改的文件进行SQL检查。

优选地，本实施例的SQL检查装置还包括：展示模块612，用于在检查模块608获取SQL语句对应的SQL执行计划，对SQL执行计划进行检查之后，使用WEB网页方式展示SQL检查的结果。

优选地，本实施例的SQL检查装置还包括：类型检查模块614，用于若文件变更类型为删除类型，则不进行SQL检查；若文件变更类型为增加类型，则获取文件的最后版本；将最后版本中的SQL信息转换为SQL语句，获取SQL语句对应的SQL执行计划，对SQL执行计划进行检查。

优选地，本实施例的SQL检查装置基于IBATIS的持久层框架。

本实施例的SQL检查装置用于实现前述多个方法实施例中的SQL检查方法，并具有相应的方法实施例的有益效果，在此不再赘述。

本申请结合SQL REVIEW的抽象性及特殊性，首先定时刷新项目信息，根据发布日期等来实现项目的搜索；当搜索到对应的项目后，点击项目，自动地实现全自动的SQL REVIEW，比如：首先自动找出有修改的文件，并进行版本比较，去除中间的rebase等信息；将SVN的日志信息展示出来，同时，对SVN日志信息进行处理，取出具体的SQL，并进行复杂的替换操作及SQL解析操作后，最后去对应的数据库中获取相应的执行计划，进行处理显示。本申请将传统的SQL REVIEW工作，通过服务器端来调用操作系统SVN管理命令，实现了自动化，并且所有结果通过WEB方式来展示，只需要点点鼠标，就可以轻松的完成SQL REVIEW；对项目中无效SVN分支能够自动进行过滤，对有效SVN分支，自动进行SVN的版本比较，并能够自动的处理rebase等信息；自动地提取文件中的SQL语句，并能够将IBATIS框架中的动态条件及标签格式化为oracle能够识别的SQL；通过解析SQL语句获到查询的表名，通过表名找到对应的具体数据库，连接数据库进行执行计划的显示；执行计划的结果的处理：根据收集的表的统计信息，对于执行计划能够作出智能的系统判断，采用保守的方式，防止出现误判的可能，最大限度的降低了人工的介入，显著提高准确率及工作效率。

通过本申请，实现了项目变更结果的准确实时web展示；引入白名单表机制，可以提高SQL REVIEW结果的准确性，可靠性；对SQL进行自动定位，并智能的分析SQL执行计划的好坏；使用2个hash结构保存修改类型的文件，更准确的处理修改文件类型的SQL；在Perl程序中，使用非常多的正则表达式，需要保证正则表达式的处理效率。由此，进一步实现了在保证REVIEW结果准确性的情况下，快速，简便地帮助DBA完成SQL REVIEW。对于各种类型的SQLMAP文件，能够实时的查看SQL的修改，控制SQLREVIEW的人力成本，更重要的是保证了结果的准确性。

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

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

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

Claims (26)

1.一种结构化查询语言SQL检查方法，其特征在于，包括：

根据文件变更类型，获取待检查文件，所述待检查文件为进行过SQL修改的文件；

对所述待检查文件进行SQL修改过滤，获取待检查的SQL修改；

将所述待检查的SQL修改转换为SQL语句；

获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查。

2.根据权利要求1所述的方法，其特征在于，所述根据文件变更类型，获取待检查文件的步骤包括：

使用Perl语言调用版本管理工具SVN命令，使所述SVN命令根据所述文件变更类型，获取修改类型的所述待检查文件。

3.根据权利要求1或2所述的方法，其特征在于，所述将对所述待检查文件进行SQL修改过滤，获取待检查的SQL修改的步骤包括：

获取所述待检查文件的当前版本的信息和所述当前版本的前次版本的信息；

根据所述当前版本的信息和所述当前版本的前次版本的信息，获取所述当前版本对应的所述待检查文件的文件内容，和所述当前版本的前次版本对应的所述待检查文件的文件内容；

将所述当前版本的前次版本对应的所述待检查文件的文件内容中的SQL内容从所述当前版本对应的所述待检查文件的文件内容中清除，获取所述待检查的SQL修改。

4.根据权利要求3所述的方法，其特征在于，所述将所述当前版本的前次版本对应的所述待检查文件的文件内容中的SQL内容从所述当前版本对应的所述待检查文件的文件内容中清除，获取所述待检查的SQL修改的步骤包括：

分别对所述当前版本对应的所述待检查文件的文件内容，和所述当前版本的前次版本对应的所述待检查文件的文件内容进行解析，并分别生成对应的SQL标识和SQL内容；

将所述SQL内容分别存放到不同的哈希Hash结构中；

根据所述SQL标识比较所述不同的Hash结构中的SQL内容，获取所述待检查的SQL修改。

5.根据权利要求1所述的方法，其特征在于，所述将所述待检查的SQL修改转换为SQL语句的步骤包括：

使用正则表达式，将所述待检查的SQL修改格式化为SQL语句。

6.根据权利要求5所述的方法，其特征在于，所述使用正则表达式，将所述待检查的SQL修改格式化为SQL语句的步骤包括：

使用所述正则表达式，将所述待检查的SQL修改中的IBATIS标记删除，将删除了所述IBATIS标记的SQL修改格式化为SQL语句。

7.根据权利要求1所述的方法，其特征在于，所述获取所述SQL语句对应的SQL执行计划的步骤包括：

使用正则表达式，从所述待检查的SQL修改的信息中获取所述待检查的SQL修改所在的数据表名；

获取所述数据表名所在的数据库信息；

连接所述数据库信息指示的数据库，从所述数据库中获取所述SQL语句对应的SQL执行计划。

8.根据权利要求7所述的方法，其特征在于，所述获取所述数据表名所在的数据库信息的步骤包括：

通过数据库对应关系表确定所述数据表名对应的数据库，获取所述数据库的信息，其中，所述数据库对应关系表用于指示数据表与数据库的对应关系，所述数据库对应关系表中还存储有所述数据库的地址信息。

9.根据权利要求1所述的方法，其特征在于，获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查的步骤包括：

使用正则表达式，从所述待检查的SQL修改的信息中获取所述待检查的SQL修改所在的数据表名；

判断所述数据表名是否在系统的白名单表中，所述白名单表中包括设定的指示SQL语句检查通过的数据表名；

若所述数据表名在所述白名单表中，则确定所述SQL语句通过检查。

10.根据权利要求1所述的方法，其特征在于，在所述根据文件变更类型，获取待检查文件的步骤之前，还包括：

检查进行过SQL修改的文件中是否存在无效修改的文件；

若是，则不对所述无效修改的文件进行所述SQL检查。

11.根据权利要求1所述的方法，其特征在于，在所述获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查的步骤之后，还包括：

使用WEB网页方式展示所述SQL检查的结果。

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

若所述文件变更类型为删除类型，则不进行所述SQL检查；

若所述文件变更类型为增加类型，则获取所述文件的最后版本；将所述最后版本中的SQL信息转换为SQL语句，获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查。

13.根据权利要求1-2、5-12中任一项所述的方法，其特征在于，所述SQL检查基于IBATIS的持久层框架。

14.一种结构化查询语言SQL检查装置，其特征在于，包括：

获取模块，用于根据文件变更类型，获取待检查文件，所述待检查文件为进行过SQL修改的文件；

修改清除模块，用于对所述待检查文件进行SQL修改过滤，获取待检查的SQL修改；

转换模块，用于将所述待检查的SQL修改转换为SQL语句；

检查模块，用于获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查。

15.根据权利要求14所述的装置，其特征在于，所述获取模块，用于使用Perl语言调用版本管理工具SVN命令，使所述SVN命令根据所述文件变更类型，获取修改类型的所述待检查文件。

16.根据权利要求14或15所述的装置，其特征在于，所述修改清除模块包括：

版本信息获取模块，用于获取所述待检查文件的当前版本的信息和所述当前版本的前次版本的信息；

版本内容获取模块，用于根据所述当前版本的信息和所述当前版本的前次版本的信息，获取所述当前版本对应的所述待检查文件的文件内容，和所述当前版本的前次版本对应的所述待检查文件的文件内容；

比较清除模块，用于将所述当前版本的前次版本对应的所述待检查文件的文件内容中的SQL内容从所述当前版本对应的所述待检查文件的文件内容中清除，获取所述待检查的SQL修改。

17.根据权利要求16所述的装置，其特征在于，所述比较清除模块包括：

解析模块，用于分别对所述当前版本对应的所述待检查文件的文件内容，和所述当前版本的前次版本对应的所述待检查文件的文件内容进行解析，并分别生成对应的SQL标识和SQL内容；

存储模块，用于将所述SQL内容分别存放到不同的哈希Hash结构中；

比较模块，用于根据所述SQL标识比较所述不同的Hash结构中的SQL内容，获取所述待检查的SQL修改。

18.根据权利要求14所述的装置，其特征在于，所述转换模块将所述待检查的SQL修改转换为SQL语句时，使用正则表达式，将所述待检查的SQL修改格式化为SQL语句。

19.根据权利要求18所述的装置，其特征在于，所述转换模块使用正则表达式，将所述待检查的SQL修改格式化为SQL语句时，使用所述正则表达式，将所述待检查的SQL修改中的IBATIS标记删除，将删除了所述IBATIS标记的SQL修改格式化为SQL语句。

20.根据权利要求14所述的装置，其特征在于，所述检查模块在获取所述SQL语句对应的SQL执行计划时，使用正则表达式，从所述待检查的SQL修改的信息中获取所述待检查的SQL修改所在的数据表名；获取所述数据表名所在的数据库信息；连接所述数据库信息指示的数据库，从所述数据库中获取所述SQL语句对应的SQL执行计划。

21.根据权利要求20所述的装置，其特征在于，所述检查模块在获取所述数据表名所在的数据库信息时，通过数据库对应关系表确定所述数据表名对应的数据库，获取所述数据库的信息，其中，所述数据库对应关系表用于指示数据表与数据库的对应关系，所述数据库对应关系表中还存储有所述数据库的地址信息。

22.根据权利要求14所述的装置，其特征在于，所述检查模块，用于使用正则表达式，从所述待检查的SQL修改的信息中获取所述待检查的SQL修改所在的数据表名；判断所述数据表名是否在系统的白名单表中，所述白名单表中包括设定的指示SQL语句检查通过的数据表名；若所述数据表名在所述白名单表中，则确定所述SQL语句通过检查。

23.根据权利要求14所述的装置，其特征在于，还包括：

过滤模块，用于在所述获取模块根据文件变更类型，获取待检查文件之前，检查进行过SQL修改的文件中是否存在无效修改的文件；若是，则不对所述无效修改的文件进行所述SQL检查。

24.根据权利要求14所述的装置，其特征在于，还包括：

展示模块，用于在所述检查模块获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查之后，使用WEB网页方式展示所述SQL检查的结果。

25.根据权利要求14所述的装置，其特征在于，还包括：

类型检查模块，用于若所述文件变更类型为删除类型，则不进行所述SQL检查；若所述文件变更类型为增加类型，则获取所述文件的最后版本；将所述最后版本中的SQL信息转换为SQL语句，获取所述SQL语句对应的SQL执行计划，对所述SQL执行计划进行检查。

26.根据权利要求14-15、18-25中任一项所述的装置，其特征在于，所述SQL检查装置基于IBATIS的持久层框架。

Images