CN113326285B - 数据库表的查询方法及装置 - Google Patents

Abstract

本申请公开了一种数据库表的查询方法及装置，方法包括：接收数据库表查询请求，并基于数据库表查询请求确定目标数据库表；基于目标数据库表中的自增主键的主键ID确定目标数据库表的总数据量；基于自增主键的主键ID将数据库表查询请求的对应任务划分为多个子任务，多个子任务中的各子任务的查询范围的并集为总数据量对应的范围；将各子任务的查询结果合并为最终结果并返回。上述技术方案，基于自增主键实现将查询全表的任务分割成很多子任务，每一个子任务的查询量远远小于查询全表的查询量，然后将所有子任务的查询结果汇总为最终结果返回，该实现在查询响应时间满足业务需求的前提下，大大提升了数据库的查询效率，优化了用户体验。

Description

数据库表的查询方法及装置

技术领域

本发明涉及数据库领域，更具体的说，是涉及一种数据库表的查询方法及装置。

背景技术

进入大数据时代，各行各业的数据量越来越多，数据存储以及数据查询的需求也日益增长。一般情况下，数据可以存储在数据库中。一个数据库存在多个数据库表，当需要将数据存储到数据库时，会通过数据库驱动器将数据存入数据库中的数据库表中；当应用程序需要这些数据的时候，会通过数据库驱动器把数据从数据库中的一个或者多个数据库表中查询出来。而数据库在存储或者查询数据的时候，相关的数据库表中本身已经存储的数据量的大小会很大程度影响数据库存储或者查询的效率。

一些应用程序运行过程中，有些操作往往需要把数据库表的所有数据都查询一遍，这种操作对于数据库来说是比较耗时的。当数据库表中存储的数据量并不是很大的时候（比如不超过十万条数据），一般耗时情况并不明显；而当数据库表中数据量巨大的时候，如百万级别、千万级别甚至上亿级别的数据量，这种数据库表查询操作会很耗时，可能一个查询数据库表的操作需要执行的时间要以小时计数，这会极大的影响软件的应用程序的响应速度，且会导致数据库查询性能低。

综上，传统的数据库表查询操作（直接通过一条查询语句将所有数据查询出来），在数据量小的情况下，并无太明显的性能问题，但是在数据量大的情况下，会导致数据库响应慢、查询性能低，甚至导致数据库崩溃。

发明内容

有鉴于此，本发明提供一种数据库表的查询方法及装置，以解决在数据量大的情况下，会导致数据库响应慢、查询性能低，甚至导致数据库崩溃的技术问题。

为了解决上述技术问题，本发明采用了如下技术方案：

一种数据库表的查询方法，包括：

接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表；

基于所述目标数据库表中的自增主键的主键ID确定所述目标数据库表的总数据量；

基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围；

将所述多个子任务中的各子任务的查询结果合并为最终结果并返回。

可选的，在所述接收数据库表查询请求前，还包括：

确定数据库是否存在整数类型的自增主键；

若不存在，为所述数据库设置整数类型的自增主键。

可选的，所述数据库表查询请求为查询数据库表中特定列的查询请求，所述特定列的数量小于所述数据库表中所有列的数量。

可选的，所述基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，包括：

基于所述总数据量和预设查询时间，将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围基于所述自增主键的主键ID划分确定，所述预设查询时间为执行所述数据库表查询请求到返回结果所能接受的时间。

可选的，所述基于所述总数据量和预设查询时间，将所述数据库表查询请求的对应任务划分为多个子任务，包括：

确定各子任务的查询数据量；

基于所述总数据量和预设查询时间，验证所述查询数据量是否满足第一要求；

若满足，将所述查询数据量作为划分宽度对所述数据库表查询请求的对应任务进行划分，得到多个子任务。

可选的，所述基于所述总数据量和预设查询时间，验证所述查询数据量是否满足第一要求，包括：

基于所述总数据量和所述查询数据量确定查询次数；

基于所述查询次数和所述查询数据量的查询执行时长确定总执行时长；

在所述总执行时长小于所述预设查询时间的情况下，确定所述查询数据量满足第一要求。

可选的，所述基于所述总数据量和预设查询时间，验证所述查询数据量是否满足第一要求，还包括：

在所述总执行时长不小于所述预设查询时间的情况下，调整所述查询数据量的大小，并重新验证调整后的查询数据量是否满足第一要求。

一种数据库表的查询装置，包括：

请求接收模块，用于接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表；

数据量确定模块，用于基于所述目标数据库表中的自增主键的主键ID确定所述目标数据库表的总数据量；

任务划分模块，用于基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围；

结果处理模块，用于将所述多个子任务中的各子任务的查询结果合并为最终结果并返回。

可选的，还包括：

库表设置模块，用于在所述请求接收模块接收数据库表查询请求前，确定数据库是否存在整数类型的自增主键，并在不存在时，为所述数据库设置整数类型的自增主键。

可选的，所述任务划分模块具体用于：基于所述总数据量和预设查询时间，将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围基于所述自增主键的主键ID划分确定，所述预设查询时间为执行所述数据库表查询请求到返回结果所能接受的时间。

经由上述的技术方案可知，与现有技术相比，本发明实施例公开了一种数据库表的查询方法及装置，方法包括：接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表；基于所述目标数据库表中的自增主键的主键ID确定所述目标数据库表的总数据量；基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围；将所述多个子任务中的各子任务的查询结果合并为最终结果并返回。上述技术方案，基于自增主键实现将查询全表的任务分割成多个子任务，每一个子任务的查询量远远小于查询全表的查询量，然后将所有子任务的查询结果汇总为最终结果返回，该实现在查询响应时间满足业务需求的前提下，大大提升了数据库的查询效率，提高查询性能，且避免数据库响应变慢或数据库崩溃的情况发生，优化了用户体验。

附图说明

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

图1为本发明实施例公开的一种数据库表的查询方法的流程图；

图2为本发明实施例公开的另一种数据库表的查询方法的流程图；

图3为本发明实施例公开的将数据库表查询请求划分为多个子任务的流程图；

图4为本发明实施例公开的验证查询数据量的流程图；

图5为本发明实施例公开的一种数据库表的查询装置的结构示意图。

具体实施方式

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

图1为本发明实施例公开的一种数据库表的查询方法的流程图，参见图1所示，数据库表的查询方法可以包括：

步骤101：接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表。

数据库表查询请求可来自应用程序。具体地，数据库表查询请求可为用户通过应用程序客户端发送的用于对数据进行查询的请求。在一些实施例中，数据库表查询请求可为全表查询，需要对数据库表中保存的所有数据进行查询，在数据库表中的数据量非常大的时候，全表查询的任务也会非常艰巨。

由于数据库中可能存在多个数据库表，而用户需要查询的数据不需要从一些无关的数据库表中进行查询，因此，可以在接收到数据库表查询请求后，基于数据库表查询请求中的请求内容（例如人员信息）确定需要到哪个或哪些数据库表中执行全表查询，确定的数据库表即为目标数据库表，所述目标数据库表的数量可为一个或多个。

步骤102：基于所述目标数据库表中的自增主键的主键ID确定所述目标数据库表的总数据量。

自增主键，即具有自增功能的主键，自增主键具有ID值，随着数据库表中存储数据的逐步增多，自增主键会对应自增长且不会重复，且为不同的数据配置不同的主键ID值。

步骤103：基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围。

在读取和查询数据库的硬件条件资源有限、高并发场景下，若要从数据库中查询大量数据，则可能会导致数据库响应时间长，查询性能低，甚至导致服务器崩溃，而且也可能会导致应用程序的服务崩溃。本发明将数据库表查询请求对应的查询操作任务分割成多个子任务，也就是说，将查询操作任务对应的查询数据量的范围分割成多个小范围的数据量以进行查询，然后将多个子任务的查询结果汇总，返回给查询方（诸如应用程序），在不改变当前硬件条件资源的前提下，就能够以低成本且高效率执行完成目标数据库表中的全部数据的查询，降低网络数据流压力，提高查询性能。

主键ID可以标识不同行的数据，将一次性全量查询的任务划分为多个少量查询的子任务，即每个子任务对应数据库表中全部数据的部分数据，使得数据库依次执行每一个任务量较小的查询操作，这使得数据库能够整体上保证处理性能，整体上提升查询效率。

步骤104：将所述多个子任务中各子任务的查询结果合并为最终结果并返回。

可以理解的是，将数据库表查询请求的对应任务划分为多个子任务，则所有子任务的查询结果的合并即为全表查询任务的结果。在将所有子任务的查询结果合并为最终结果后，将最终结果作为所述数据库表查询请求的响应结果返回。

本实施例所述数据库表的查询方法基于自增主键实现将查询目标数据库表的任务分割成多个子任务，每一个子任务的查询量远远小于查询目标数据库表全表的查询量，然后将所有子任务的查询结果汇总为最终结果返回，该实现在查询响应时间满足业务需求的前提下，大大提升了数据库的查询效率，提高查询性能，且避免数据库响应变慢或数据库崩溃的情况发生，优化了用户体验。另外，在查询目标数据库表中的数据量很大时，数据库软件需要的缓冲时间长，会导致使用数据库在查询响应的过程中出现停顿或卡死的现象，而且由于数据库需要充分时间通过数据流返回查询的最终结果，会导致数据库无法同时处理其它的查询服务，因此会导致数据库响应变慢，甚至崩溃，而且会影响其它应用程序的相应服务。本申请基于自增主键实现将查询目标数据库表的任务分割成多个子任务进行查询，可以在进行查询工作时缩短数据库软件的缓冲时间，避免使用数据库在查询工作的过程中出现停顿或卡死，而且能够提高数据库通过数据流返回查询的最终结果的速度，避免影响数据库处理其它的查询服务，从而避免影响其它应用程序的相应服务。

一个实现中，所述数据库表的查询方法在实施前还可以包括其他步骤，参见图2，为本发明实施例公开的另一种数据库表的查询方法的流程图，结合图2所示，本实现中，数据库表的查询方法可以包括：

步骤201：确定数据库是否存在整数类型的自增主键，若存在，直接进入步骤203；若不存在，进入步骤202。

自增主键与数据库表对应，自增主键的值（即主键ID）能唯一地标识数据库表中的每一行，用于索引数据库表的每行数据记录，主键ID可以配置为根据数据库表中数据记录的插入，由数据库软件控制，自动将该行插入的数据记录的主键ID设置为上一行数据记录的主键ID值加1，因此数据库表中的主键ID随行依次递增。通过自增主键索引数据库表中的数据记录可以提升查询速度。

步骤202：为所述数据库设置整数类型的自增主键。

实现中，如果数据库存在主键，则检查主键是否是整数类型并且是否是自增的；如果不是，则修改数据库表的结构，为数据库表设置一列整数类型（诸如int类型）、无符号自增的索引以作为自增主键。其中，为数据库表设置索引的过程也就是更改数据库表约束的过程，数据库软件可以根据设置索引的约束特性，自动为数据库表添加索引以作为自增主键。

如果数据库不存在主键，则修改表结构，增加整数类型（诸如int类型）、无符号自增的索引以作为自增主键。其中，为数据库表设置索引的过程也就是更改数据库表约束的过程，数据库软件可以根据设置索引的约束特性，自动为数据库表添加索引以作为自增主键。

需要说明的是，整数类型+自增主键，保证了数据是有序的，这样方便后续分段式查询（也即前述分子任务查询）的时候能通过自增主键迅速锁定当前需要查询的数据的范围。

对于数据库表的查询，如果没有使用自增主键，那么每次的小范围查询，会把整个数据库表查询一遍，这样效率会比较低，并且随着数据库表中数据量的不断增大，效率降低的会越来越明显，使用自增主键可以有效提升查询效率。

主键的设置能够在数据库表中的数据量动态增加的过程中仍能快速查询到目标行范围的数据。例如，在一个业务场景下，有一千个用户的基本数据（基本数据可包括身份证号码、手机号码、身高、年龄、性别等）存入数据库表中，查询请求的查询条件为从数据库表中查询身高在165cm到175cm的用户。在数据库表没有主键的情况下， 数据库表中添加的前述一千个用户的基本数据是按行随机存储在数据库表中的，现在要选出符合查询条件的用户，需要一行行筛选完所有数据，才能查询到所需的用户的基本数据；在数据库表有主键的情况下，假设设置用户的身高作为主键，当每在数据库表中添加一个用户的基本数据时，会额外按照身高从低到高的顺序存一份数据只存身高和身份证号码，这时候需要筛选某个范围身高的人群时，只需要在额外的这份数据中根据身高范围筛选出这批数据，数据里面的身份证号对应了要查询的人，再根据身份证号从总人群中查询出来这些人的详情。数据量越大，带索引的查询，速度优势越明显。需要说明的是，对于相同身高的人员，在存储其身高时，由于需要符合主键的自增特性，可以以身高单位低一个数量级或两个数量级的数字的不同来区分，例如，两个人身高都是180cm，则在存储两条数据时，第一个人的身高数据是180.00cm，第二个人的身高数据是180.01cm。随着存储的人员信息的不断增加，如果还有更多的人身高是180cm，则可以按照上述方式依次增加最后一位的数字来表示。

步骤202后，进入步骤203。

步骤203：接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表。

步骤204：基于所述目标数据库表中的自增主键的主键ID确定所述目标数据库表的总数据量。

步骤205：基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围。

步骤206：将所述多个子任务中的各子任务的查询结果合并为最终结果并返回。

本实施例中，在数据库表的查询方法正式实施前，首先确保数据库具有整数类型的自增主键，为后续的数据库表的查询方法能够顺利实施提供基础条件，从而实现数据库查询效率和查询性能的提升，一定程度上避免数据库响应变慢或数据库崩溃的情况发生。

前述实施例中，所述数据库表查询请求可以为查询所述数据库表中特定列的查询请求，所述特定列的数量小于所述数据库表中所有列的数量。

在该实现中，需要优化查询数据库查询语句，也即SQL（Structured QueryLanguage，结构化查询语言），通过优化查询语句实现只查询需要的列，即在查询语句中对需要查询的内容进行精确限定。例如，查询语句对应的内容是“查询人员信息”，则需要将所有人员的所有属性信息都查询（属性信息包括身份证号、性别、年龄、身高、体重、职业等）；而优化查询语句实现只查询需要的列，查询语句对应的内容可以是“查询人员信息的身份证号” 。传统查询语句，通常一次将表中所有列都查询出来，而实际业务场景下往往只需要使用部分列数据。数据库底层引擎查询到所有数据之后，会通过网络io（即网络数据流）将数据传输给查询方，数据流传输需要时间，如果在查询语句中查询额外不需要使用的列，会导致大量的无效数据流操作，增大数据流压力，也会影响查询响应时间，因此，对于数据库表查询，可以只查询需要的数据列即可。

结合前述自增主键的内容，数据库已经建立了索引，索引就是数据库表的自增主键。则可基于自增主键使用分段查询的方式完成数据库表查询请求对应的查询操作，例如，一个实现中，数据库表查询请求为第一季度销售数据，销售数据对应的数据库表中共有1万多条数据，这1万多条数据以序号作为自增主键，则基于主键ID，可以对这1万多条数据进行任务划分，每个子任务中包含1000条数据，则划分后的子任务中，第一个子任务对应的主键ID范围是[1，1000]，第二个子任务对应的主键ID范围是[1001，2000]……，根据数据库索引查询的原理当查询主键ID为1-1000这个范围的数据时，先会通过索引锁定一个范围（可能是0-15000），然后在这个范围内查询出主键ID在0-1000这个范围的数据。

对于数据库表查询，需要使用合理的索引。本实现方案以主键ID作为查询条件，主键ID也是唯一索引，基于数据库索引构造原理，使用主键ID的查询效率会比其它索引或者无索引条件快。其中的其他索引如采用“年龄”、“身高”属性作为索引。

一个实现中，所述基于自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，可以包括：基于所述总数据量和预设查询时间，将所述数据库表查询请求的对应任务划分为多个子任务。其中，多个子任务中的各子任务的查询范围基于所述自增主键的主键ID划分确定，所述预设查询时间为执行所述数据库表查询请求到返回结果所能接受的时间。

图3为本发明实施例公开的将数据库表查询请求划分为多个子任务的流程图，如图3所示，所述基于所述总数据量和预设查询时间，将所述数据库表查询请求的对应任务划分为多个子任务，可以包括：

步骤301：确定各子任务的查询数据量。

步骤302：基于所述总数据量和预设查询时间，验证所述查询数据量是否满足第一要求。

步骤303：若满足，将所述查询数据量作为划分宽度对所述数据库表查询请求的对应任务进行划分，得到多个子任务。

其中，验证查询数据量是否满足第一要求的具体实现可参见图4，图4为本发明实施例公开的验证查询数据量的流程图，如图4所示，所述基于所述总数据量和预设查询时间，验证所述查询数据量是否满足第一要求，可以包括：

步骤401：基于所述总数据量和所述查询数据量确定查询次数。

步骤402：基于所述查询次数和所述查询数据量的查询执行时长确定总执行时长。

步骤403：在所述总执行时长小于所述预设查询时间的情况下，确定所述查询数据量满足第一要求。

步骤404：在所述总执行时长不小于所述预设查询时间的情况下，调整所述查询数据量的大小，并重新验证调整后的查询数据量是否满足第一要求，即返回步骤401，直至总执行时长小于所述预设查询时间。其中，第一要求可以但不限制为总执行时长小于预设查询时间。

在一个全表查询的具体实现中，方案的实施可以包括如下内容：

1、确定idMax（自增主键ID的最大值）和idMin（自增主键ID的最小值）。

先查询到自增主键的最小值，记为idMin，再查询到自增主键的最大值记为idMax，则所有数据的主键ID都在idMin和idMax的范围内。需要说明的是，在不是全表查询的实现中，idMin为在确定的查询范围内的主键ID最小值，idMax为在确定的查询范围内的主键ID最大值。确定的查询范围小于全表查询的查询范围，查询范围的确定可基于数据库表查询请求来实现，例如一个数据库表存储了2020年全年的销售数据，若查询请求表征内容是“查询2020年度第一季度销售数据”，则不需要对该数据库表进行全表查询，而仅对该数据库表中时间处于2020年1月1日到2020年3月31日范围内的数据进行查询；其中时间处于2020年1月1日到2020年3月31日范围内的数据为确定的查询范围。

2、根据主键ID计算全表数据量totalCount，也即前文所述目标数据库表的总数据量。

通过idMax-idMin+1，能够计算出一个数值，该数值就是整个表中的数据量（目标数据库表的总数据量），记为totalCount。

3、预估全表查询所能接受的时间time。

预估全表查询所能承受的最大时间，记为time（即预设查询时间），其中所能承受的最大时间可根据实际业务场景下上游（调用该方法查询的应用程序的服务接口）最大等待时间而确定。

4、确定每次小范围查询的数量perCount，也即确定每个子任务的查询数据量。

根据实际业务场景，预估每个子任务需要查询的数据量，记为perCount。

5、计算总查询次数totalTimes。

计算当前perCount下需要数据库查询的次数totalTimes = totalCount/perCount+1。

6、调整数据量perCount和time。

通过数据库客户端软件，使用perCount多次执行查询语句，计算出平均时间avgTime，计算出总耗时realTime。

realTime = avgTime * totalTimes。

当realTime >= time时，需要调整perCount，适当增加perCount，每次增大或者缩小百分之20（也可以是其他数值，具体可根据应用场景按需设定），不断的调整，直到最终算出来的realtime小于预估time。如果进行了多轮调整，还不能满足要求，则考虑适当增大time，重复6的操作直到满足条件。

本实现中，详细说明了确定各子任务的查询数据量的具体实现，该实现中可以动态的对子任务的查询数据量进行调整，使得其取值能够满足预设查询时间的要求，在保证任务划分工作能够顺利进行的前提下，也不会导致用户等待时间过长而影响用户的使用体验。另外，本申请可在硬件条件有限的情况下，通过将数据库表查询请求对应的查询操作任务分割成多个子任务，以将查询操作任务对应的查询数据量的范围分割成多个小范围的数据量来进行查询，然后将多个子任务的查询结果汇总返回给查询方，并且本申请可基于数据库表查询请求对应任务的总数据量和预设查询时间动态调整各子任务的查询数据量，因此在不改变当前硬件条件资源的前提下，就能够高效完成数据库表查询请求对应的查询任务，降低网络数据流压力，提高查询性能。并且由于可灵活调整各子任务的查询数据量，因此无论数据库表查询请求对应任务的总数据量为多少，都能保证数据库表的查询策略始终保证最优，也就是在高效查询的前提下确定各子任务的查询数据量的最优值，使得数据库表查询请求对应任务的查询时间可以控制在预设查询时间内，提高查询效率和查询通用性。

为了更好的了解本申请方案，下面列举两个例子辅助说明。

一个例子中，应用程序在运行过程中需要从数据库查询10000条数据，但由于10000条数据的数据量太大，一次性查询需要的内存资源较大，同时也会导致没有足够资源处理其他工作。反映到程序里面就是：服务器内存是有限的，一次性查询数据量大，数据库需要的缓冲时间长，响应慢，甚至会导致卡死，另一方面，数据库需要充分时间通过数据流传送查询的数据结果，导致数据库无法同时处理其它的查询服务，因此会导致数据库响应变慢，甚至崩溃，而且会影响其它应用程序的服务。

另一个例子：数据库有多个任务需要处理，由于其中一个任务的工作量很大，如果数据库集中资源处理这一个任务，需要的时间会很久，则很多其他的任务都要等待这个任务完成后才能够进行，数据库的整体处理效率就会非常低；而如果将这个工作量很大的任务划分为多个处理量小一点的子任务，将这些划分后的子任务与其他任务来穿插轮流进行处理，则会提升数据库的整体处理效率；这样，在多个应用服务一起查询数据库的时候，可以提高整体处理效率，而不会出现个别服务可以用，其它服务只能暂停等待的情况。

本实现方案在软件层面的一个实际应用可以但不限于如下：

执行查询的伪sql为select c1,c2, c3, ... from table where id >= id1 andid <= id2。其中的c1、c2和c3表示数据库表中需要选择的属性（列），id1表示最小的ID主键值，id2表示最大的ID主键值。

当确定好前述步骤的数据（c1、c2、c3、id1、id2等）之后，在程序中执行循环操作。在一些实施例中，具体逻辑如下：

在目标数据库表中通过sql语句获取到主键ID最小值（idMin）和主键ID最大值（idMax），基于主键ID最小值（idMin）和主键ID最大值（idMax）获取目标数据库表的总数据量，总数据量为数据库表查询请求的对应任务索要查询的总数据量；

① 创建一个容器存储查询到的数据list，数据list即子任务查询到的查询结果;

② 循环执行totalTimes次；

每执行一次查询语句，将数据添加到数据list中，每次执行的查询语句为

select c1, c2, c3, ... from table where id >= idMin and id <idMin+perCount；其中的perCount表示子任务查询量，此语句表示从最小主键ID值这一侧开始的第一个子任务的查询范围中查询c1, c2, c3, ...

select c1, c2, c3, ... from table where id >= idMin+perCount and id <idMin+perCount+perCount；此语句表示从第二个子任务的查询范围中查询c1, c2, c3,...

select c1, c2, c3, ... from table where id >= idMin+perCount+perCountand id <idMin+perCount+perCount+perCount...；此语句表示从第三个子任务的查询范围中查询c1, c2, c3, ...

...

③ 执行完循环之后，list中存放的就是全表数据。

本申请实施例公开的数据表的查询方法，能够根据软件实际业务场景要求，动态调整分批策略，最终使得查询响应时间满足业务要求，提高查表效率，提升客户的使用体验。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

上述本发明公开的实施例中详细描述了方法，对于本发明的方法可采用多种形式的装置实现，因此本发明还公开了一种装置，下面给出具体的实施例进行详细说明。

图5为本发明实施例公开的一种数据库表的查询装置的结构示意图，参见图5所示，数据库表的查询装置50可以包括：

请求接收模块501，用于接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表。

数据量确定模块502，用于基于所述目标数据库表中的自增主键的主键ID确定所述目标数据库表的总数据量。

任务划分模块503，用于基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围。

结果处理模块504，用于将所述多个子任务中的各子任务的查询结果合并为最终结果并返回。

本实施例中，所述数据库表的查询装置基于自增主键实现将查询全表的操作分割成很多小范围的查询，然后所有查询结果汇总为最终结果返回，该实现在查询响应时间满足业务需求的前提下，大大提升了数据库的查询效率，提高查询性能，且避免数据库响应变慢或数据库崩溃的情况发生，优化了用户体验。

一个实现中，数据库表的查询装置除了上述各模块，还可以包括：库表设置模块，用于在所述请求接收模块接收数据库表查询请求前，确定数据库是否存在整数类型的自增主键，并在不存在时，为所述数据库设置整数类型的自增主键。

一个实现中，所述数据库表查询请求为查询所述数据库表中特定列的查询请求，所述特定列的数量小于所述数据库表中所有列的数量。

一个实现中，所述任务划分模块具体可用于：基于所述总数据量和预设查询时间，将所述数据库表查询请求的对应任务划分为多个子任务，多个子任务中的各子任务的查询范围基于所述自增主键的主键ID划分确定，所述预设查询时间为执行所述数据库表查询请求到返回结果所能接受的时间。

一个实现中，所述任务划分模块可以包括：子任务确定模块，用于确定各子任务的查询数据量；数据验证模块，用于基于所述总数据量和预设查询时间，验证所述查询数据量是否满足第一要求；任务划分子模块，用于在数据验证模块验证满足第一要求时，将所述查询数据量作为划分宽度对所述数据库表查询请求的对应任务进行划分，得到多个子任务。

一个实现中，数据验证模块具体可用于：基于所述总数据量和所述查询数据量确定查询次数；基于所述查询次数和所述查询数据量的查询执行时长确定总执行时长；在所述总执行时长小于所述预设查询时间的情况下，确定所述查询数据量满足第一要求；在所述总执行时长不小于所述预设查询时间的情况下，调整所述查询数据量的大小，并重新验证调整后的查询数据量是否满足第一要求。

上述实施例中的所述的任意一种数据库表的查询装置包括处理器和存储器，上述实施例中的请求接收模块、数据量确定模块、任务划分模块、结果处理模块等均作为程序模块存储在存储器中，由处理器执行存储在所述存储器中的上述程序模块来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序模块。内核可以设置一个或多个，通过调整内核参数来实现回访数据的处理。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器（RAM）和/或非易失性内存等形式，如只读存储器（ROM）或闪存（flash RAM），存储器包括至少一个存储芯片。

本发明实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现上述实施例中所述的数据库表的查询方法。

本发明实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述实施例中所述的数据库表的查询方法。

进一步，本实施例提供了一种电子设备，包括处理器以及存储器。其中存储器用于存储所述处理器的可执行指令，所述处理器配置为经由执行所述可执行指令来执行上述实施例中所述的数据库表的查询方法。

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

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

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (6)

1.一种数据库表的查询方法，其特征在于，包括：

接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表；

在所述目标数据库表中获取自增主键的主键ID最小值和自增主键的主键ID最大值，基于所述自增主键的主键ID最小值和所述自增主键的主键ID最大值确定所述目标数据库表的总数据量；

基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围，所述自增主键的主键ID作为所述数据库表查询请求的查询条件；

将所述多个子任务中的各子任务的查询结果合并为最终结果并返回；

其中，所述基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，包括：确定各子任务的查询数据量；基于所述总数据量和所述查询数据量确定查询次数；基于所述查询次数和所述查询数据量的查询执行时长确定总执行时长；在所述总执行时长小于预设查询时间的情况下，确定所述查询数据量满足第一要求；将所述查询数据量作为划分宽度对所述数据库表查询请求的对应任务进行划分，得到多个子任务，所述多个子任务中的各子任务的查询范围基于所述自增主键的主键ID划分确定，所述预设查询时间为执行所述数据库表查询请求到返回结果所能接受的时间。

2.根据权利要求1所述的数据库表的查询方法，其特征在于，在所述接收数据库表查询请求前，还包括：

确定数据库是否存在整数类型的自增主键；

若不存在，为所述数据库设置整数类型的自增主键。

3.根据权利要求1所述的数据库表的查询方法，其特征在于，所述数据库表查询请求为查询数据库表中特定列的查询请求，所述特定列的数量小于所述数据库表中所有列的数量。

4.根据权利要求1所述的数据库表的查询方法，其特征在于，所述基于所述总数据量和预设查询时间，验证所述查询数据量是否满足第一要求，还包括：

在所述总执行时长不小于所述预设查询时间的情况下，调整所述查询数据量的大小，并重新验证调整后的查询数据量是否满足第一要求。

5.一种数据库表的查询装置，其特征在于，包括：

请求接收模块，用于接收数据库表查询请求，并基于所述数据库表查询请求确定目标数据库表；

数据量确定模块，用于在所述目标数据库表中获取自增主键的主键ID最小值和自增主键的主键ID最大值，基于所述自增主键的主键ID最小值和所述自增主键的主键ID最大值确定所述目标数据库表的总数据量；

任务划分模块，用于基于所述自增主键的主键ID将所述数据库表查询请求的对应任务划分为多个子任务，所述多个子任务中的各子任务的查询范围的并集为所述总数据量对应的范围，所述自增主键的主键ID作为所述数据库表查询请求的查询条件；

结果处理模块，用于将所述多个子任务中的各子任务的查询结果合并为最终结果并返回；

所述任务划分模块具体用于：确定各子任务的查询数据量；基于所述总数据量和所述查询数据量确定查询次数；基于所述查询次数和所述查询数据量的查询执行时长确定总执行时长；所述总执行时长小于预设查询时间的情况下，确定所述查询数据量满足第一要求；将所述查询数据量作为划分宽度对所述数据库表查询请求的对应任务进行划分，得到多个子任务，所述多个子任务中的各子任务的查询范围基于所述自增主键的主键ID划分确定，所述预设查询时间为执行所述数据库表查询请求到返回结果所能接受的时间。

6.根据权利要求5所述的数据库表的查询装置，其特征在于，还包括：

库表设置模块，用于在所述请求接收模块接收数据库表查询请求前，确定数据库是否存在整数类型的自增主键，并在不存在时，为所述数据库设置整数类型的自增主键。

Images