CN118567856A - Asynchronous management method and device for database query task and computer equipment - Google Patents

Abstract

The present application relates to a method, device, computer equipment, computer-readable storage medium and computer program product for asynchronous management of database query tasks. The method comprises: determining idle threads, and if the number of idle threads exceeds a preset thread threshold, then screening out multiple target database query tasks from a preparatory task queue according to the number of idle threads; splitting each target database query task into multiple subtasks; for each of the multiple subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, then treating the targeted subtask as a shared subtask; assigning multiple target database query tasks and shared subtasks to idle threads for processing. The use of this method can complete all query tasks faster, improve query efficiency, and reduce the pressure on a single database point by dispersing the query load.

Description

Database query task asynchronous management method, device and computer equipment

Technical Field

The present application relates to the field of computer technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium and computer program product for asynchronous management of database query tasks.

Background Art

With the rapid development of information technology, databases have gradually become a key tool for enterprises and individuals to store and query data. At the same time, as the data stored in the database becomes more complex and large, achieving efficient and flexible data acquisition will face huge challenges.

In some cases, in order to obtain data in the application, we usually adopt the traditional method, that is, by providing a specific API and limiting the input parameters. However, this method has certain limitations. When faced with complex query requirements, its flexibility is limited and it cannot meet the requirements. Secondly, when dealing with large amounts of data and complex queries, the traditional synchronous query method often leads to low query efficiency and may even cause database blocking.

Summary of the invention

Based on this, it is necessary to provide a method, device, computer equipment, computer-readable storage medium and computer program product for asynchronous management of database query tasks that can improve query efficiency and alleviate database pressure in response to the above technical problems.

In a first aspect, the present application provides a method for asynchronously managing database query tasks, comprising:

Determine idle threads, and if the number of the idle threads exceeds a preset thread threshold, select multiple target database query tasks from the preparation task queue according to the number of the idle threads;

Splitting each of the target database query tasks into multiple subtasks;

For each of the multiple subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, then the targeted subtask is used as a shared subtask;

The multiple target database query tasks and the shared subtasks are assigned to the idle thread for processing.

In a second aspect, the present application also provides a database query task asynchronous management device, comprising:

A first determination module is used to determine idle threads, and if the number of the idle threads exceeds a preset thread threshold, a plurality of target database query tasks are screened out from a preparation task queue according to the number of the idle threads;

A splitting module, used for splitting each of the target database query tasks into multiple subtasks;

A second determination module is used for, for each of the plurality of subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, to use the targeted subtask as a shared subtask;

The allocation module is used to allocate the multiple target database query tasks and the shared subtasks to the idle threads for processing.

In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

Determine idle threads, and if the number of the idle threads exceeds a preset thread threshold, select multiple target database query tasks from the preparation task queue according to the number of the idle threads;

Splitting each of the target database query tasks into multiple subtasks;

For each of the multiple subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, then the targeted subtask is used as a shared subtask;

The multiple target database query tasks and the shared subtasks are assigned to the idle thread for processing.

In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

Determine idle threads, and if the number of the idle threads exceeds a preset thread threshold, select multiple target database query tasks from the preparation task queue according to the number of the idle threads;

Splitting each of the target database query tasks into multiple subtasks;

For each of the multiple subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, then the targeted subtask is used as a shared subtask;

The multiple target database query tasks and the shared subtasks are assigned to the idle thread for processing.

In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

Determine idle threads, and if the number of the idle threads exceeds a preset thread threshold, select multiple target database query tasks from the preparation task queue according to the number of the idle threads;

Splitting each of the target database query tasks into multiple subtasks;

For each of the multiple subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, then the targeted subtask is used as a shared subtask;

The multiple target database query tasks and the shared subtasks are assigned to the idle thread for processing.

The above-mentioned database query task asynchronous management method, device, computer equipment, computer-readable storage medium and computer program product first determine the idle threads. If the number of the idle threads exceeds the preset thread threshold, multiple target database query tasks are screened out from the preparatory task queue according to the number of the idle threads; thread resources are fully utilized to avoid idle waste of thread resources. Then, each of the target database query tasks is split into multiple subtasks; it is conducive to parallel processing, and each subtask can be executed concurrently in a separate thread, further improving the query efficiency. Then, for each of the multiple subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, the targeted subtask is used as a shared subtask; unnecessary repeated calculations are avoided, and the overall calculation cost is reduced. Finally, the multiple target database query tasks and the shared subtasks are assigned to the idle threads for processing. It is achieved to ensure that all threads can be fully utilized and maximize the parallel processing capability of the system. This can not only complete all query tasks faster and improve query efficiency, but also reduce the pressure on a single database point by dispersing the query load, allowing the database to serve multiple concurrent requests more smoothly and improve the overall stability of the system.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments of the present application or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

FIG1 is an application environment diagram of a method for asynchronous management of database query tasks in one embodiment;

FIG2 is a schematic diagram of a flow chart of a method for asynchronously managing database query tasks in one embodiment;

FIG3 is a schematic diagram of a flow chart of a method for asynchronously managing database query tasks in another embodiment;

FIG4 is a structural block diagram of a database query task asynchronous management device in one embodiment;

FIG5 is a structural block diagram of a device for asynchronously managing database query tasks in another embodiment;

FIG. 6 is a diagram showing the internal structure of a computer device in one embodiment.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

The database query task asynchronous management method provided in the embodiment of the present application can be applied to the application environment shown in FIG. 1. Among them, the terminal 102 communicates with the server 104 through the network. The data storage can store the data that the server 104 needs to process. The data storage can be integrated on the server 104, or it can be placed on the cloud or other network servers. The terminal 102 generates a database query task asynchronous management request, and then sends the database query task asynchronous management request to the server 104, so that the server 104 assigns multiple target database query tasks and shared subtasks to idle threads for processing. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. The portable wearable device can be a smart watch, a smart bracelet, a head-mounted device, etc. The head-mounted device can be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. The server 104 may be an independent physical server, or a server cluster or distributed server consisting of multiple physical servers, or a cloud server that provides cloud computing services.

In an exemplary embodiment, as shown in FIG2 , a method for asynchronous management of database query tasks is provided, which is described by taking the method applied to step 104 in FIG1 as an example, and includes the following steps 202 to 208 . Among them:

Step 202, determining idle threads, if the number of idle threads exceeds a preset thread threshold, then screening out a plurality of target database query tasks from the preparation task queue according to the number of idle threads.

Idle threads refer to threads that have completed the previous task and are waiting for new tasks to be assigned in a multithreaded environment. They have no workload being executed and can accept and start processing new tasks at any time. The preset thread threshold refers to a pre-set value that indicates how many idle threads are allowed to exist. When it is detected that the number of idle threads exceeds this threshold, the corresponding action will be triggered, such as taking tasks from the standby task queue for processing. The standby task queue refers to a first-in-first-out (FIFO) queue or priority queue for storing tasks waiting to be executed. These tasks have not been assigned to any thread, but are queued and waited for threads to take and execute according to a certain strategy (such as first-come, first-served, priority, etc.). The target database query task refers to those pending database operation tasks. These tasks may not be assigned to threads for execution for various reasons. They will be selected for further processing only when certain conditions (such as sufficient idle threads) are met. Optionally, the target database query task consists of multiple SQL scripts, and the data is queried in the form of temporary tables.

Specifically, first, in a multi-threaded environment, the status of all threads is monitored in real time to identify which threads have completed previously assigned tasks and are currently idle, that is, there is no work in progress. Then, when it is detected that the number of idle threads exceeds a preset threshold, it indicates that there is surplus resources (threads). At this time, in order to use resources more efficiently, the next task scheduling strategy can be started. Finally, according to the specific number of current idle threads, the corresponding number of target database query tasks is selected from the pre-task queue. The pre-task queue stores various database query tasks waiting to be executed, and these tasks are arranged according to certain strategies (for example, first-in-first-out, priority, etc.).

Step 204: split each target database query task into multiple subtasks.

Among them, a subtask refers to a part of the target database query task, which represents a specific, independently executable operation in the original task. For example, in a complex database query task, a subtask may include querying a table, preliminary filtering of data, statistical calculations, etc. By splitting, the original single large task becomes multiple relatively small and logically clear subtasks.

Specifically, first, for each target database query task selected from the preparation task queue, it is divided into multiple smaller-scale, logically relatively independent subtasks. The reason for this is that a single large query task may contain multiple steps, some of which can be executed in parallel, and different large query tasks may have the same subtasks or interdependent subtasks.

Step 206 : for each of the multiple subtasks, if it is determined that other subtasks are dependent on the targeted subtask, or have other subtasks that are the same as the targeted subtask, then the targeted subtask is used as a shared subtask.

Among them, shared subtasks refer to the identification of certain subtasks with specific attributes after splitting the target database query task into multiple subtasks, that is, they may be prerequisites for the execution of other subtasks, or the operations they perform are exactly the same or partially the same as other subtasks. Such subtasks are defined as "shared subtasks".

Specifically, after splitting the target database query task into multiple subtasks, check the association between these subtasks. If it is found that the execution of other subtasks must depend on the results of the subtask currently being checked (for example, the data obtained by one subtask is the basic data required for the calculation of another subtask), it means that there is a dependency between the two subtasks. At the same time, it will also be determined whether there are subtasks with the same or similar execution content, that is, there are multiple subtasks that need to query the same database record or execute the same calculation logic. In this case, even if they are not directly dependent on each other, the result of executing one of the subtasks can be reused by other subtasks to avoid repeated calculations and waste of resources. Then when one of the above two situations is confirmed, the subtask in question will be marked as a "shared subtask". This means that the result of this subtask not only serves itself, but also needs to be provided to other subtasks that depend on it, or used to replace those subtasks with the same execution content, so as to achieve the purpose of improving execution efficiency and reducing computing overhead.

Step 208: assign multiple target database query tasks and shared subtasks to idle threads for processing.

Specifically, independent and shared subtasks will be evenly and effectively assigned to idle threads for processing based on their execution dependencies and resource requirements. This makes full use of the advantages of parallel computing, ensuring that multiple query requests can be processed simultaneously, maximizing query speed, and effectively alleviating database pressure by reasonably allocating tasks and sharing calculation results, ensuring stability and performance in high-concurrency scenarios.

In one of the embodiments, a target screening number of database query tasks is determined based on the number of idle threads; the execution status information of each database query task in the preparation task queue is obtained, and the database query tasks whose execution status information is that they have not been executed are determined as candidate database query tasks; and the target screening number of target database query tasks are screened out from the candidate database query tasks.

Among them, the execution status information refers to the current working stage or completion status of the database query task. It can be understood that this application does not limit the content of the execution status information, and it can be set according to actual needs. Optionally, the execution status information includes but is not limited to not yet executed, executing, completed, failed, and canceled.

Specifically, first monitor the number of idle threads in the current environment in real time. Based on the preset thread management strategy, determine how many database query tasks can be processed simultaneously according to the number of current idle threads. For example, if it is stipulated that idle threads must retain a certain redundancy, or query tasks are allocated according to a certain ratio (such as 70% of the number of idle threads), then calculate the target screening number that can be allocated to query tasks based on this principle.

Secondly, the preparatory task queue stores a list of pending database query tasks. The preparatory task queue is traversed to obtain the execution status information of each query task one by one. The execution status information includes but is not limited to: whether the execution has started, whether the execution has been completed, whether the execution has failed, etc.

Then, after obtaining the execution status of each query task, those tasks with the execution status of "not yet executed" are filtered out. These unexecuted tasks are considered candidate database query tasks, which are not occupied by any thread and can be assigned to idle threads for processing.

Finally, according to the calculated target number of screening tasks, a corresponding number of tasks will be selected from the candidate database query tasks. It can be understood that the principle of selection can be based on the order in which the tasks arrive at the queue (FIFO, first in first out), or based on the priority of the task, the estimated execution time and other factors. Once the target number of screening tasks is selected, these tasks will be marked as tasks to be executed and are ready to be taken over by the idle thread for execution.

Since the execution status of tasks is clear and controllable, it is easier to make corresponding adjustments and optimizations when expanding capacity or adjusting resource allocation strategies, which is conducive to long-term operation and maintenance management and performance improvement. It can process more tasks when there are sufficient idle thread resources, and appropriately reduce the amount of task processing when resources are tight. It has good elastic scaling capabilities and can adapt to different load scenarios.

In one of the embodiments, the time of entry of each candidate database query task in the preparatory task queue is obtained; a target number of target database query tasks are sequentially screened out from multiple candidate database query tasks in the preparatory task queue in order of entry time from far to near; or the query priority of each candidate database query task in the preparatory task queue is obtained; a target number of target database query tasks are sequentially screened out from multiple candidate database query tasks in the preparatory task queue in order of query priority from high to low.

Among them, the entry time refers to the specific time point when the candidate database query task enters the preparatory task queue. When scheduling tasks, tasks are screened in order from the longest to the shortest entry time, which means following the "first in, first out" principle. Tasks that join the preparatory task queue earlier will be assigned to idle threads for processing first. This method treats all tasks fairly and ensures that the order in which tasks are processed is consistent with the order in which they request services. Query priority refers to a weight value assigned to database query tasks to indicate the importance or urgency of the task. When filtering tasks in order from high to low query priority, tasks with high priority will be assigned to idle threads for execution first. This strategy allows flexible task processing and prioritizes more urgent or important query requests, which helps optimize the overall service quality and resource utilization efficiency.

Specifically, it can be understood that the present application includes at least two task scheduling strategies. In the first task scheduling strategy, first, for each candidate database query task in the preparatory task queue, the specific time (entry time) of their entry into the queue will be recorded. Then all candidate tasks are sorted according to the entry time, that is, the earliest entry time is in front, and the latest is in the back. Then, based on the number of current idle threads and the set target screening rules, the number of target database query tasks that need to be screened out from the preparatory task queue this time is determined. Finally, from the sorted candidate task list, tasks are selected in order from front to back until the number of selected tasks reaches the target screening number. In this way, the task that enters the preparatory task queue earliest will be selected first, following the "first in, first out" principle.

In the second task scheduling strategy, a query priority attribute is first set for each candidate database query task in the preparatory task queue to reflect the urgency or importance of the task. Then all candidate tasks are sorted according to the query priority, that is, the highest priority task is in front and the lowest priority task is in the back. Then, based on the idle thread resources and the set target screening rules, the number of target database query tasks that need to be screened is determined. Finally, from the priority-sorted candidate task list, tasks are selected in order from high to low until the number of selected tasks reaches the target screening number. In this way, the query task with the highest priority will be selected first and assigned to the idle thread for execution.

Since two different task scheduling strategies are adopted, it can be ensured that when there are idle threads, database query tasks are reasonably and efficiently allocated according to certain rules. The first strategy focuses more on fair queuing of tasks, while the second strategy focuses on the urgency and importance of tasks.

In one of the embodiments, the targeted subtask is matched with other subtasks for statement parameters to obtain parameter matching results; the targeted subtask is matched with other subtasks for data range to obtain range matching results; the targeted subtask is matched with other subtasks for output format to obtain format matching results; when it is determined based on the parameter matching results, the range matching results and the format matching results that other subtasks are dependent on the targeted subtask, or have other subtasks that are the same as the targeted subtask, the targeted subtask is used as a shared subtask.

Statement parameters refer to variables, placeholders, or dynamic values used in query statements. These parameters make queries more flexible and versatile, and can adapt to different query conditions or data filtering requirements. Optionally, statement parameters include but are not limited to bind variables, query parameters, and placeholders in query templates.

Data range refers to the restriction conditions of the data set involved in the query operation in the query task, which determines which records are retrieved from the database. Optionally, the data range includes but is not limited to logical conditions, paging and offset, etc.

Output format refers to the presentation and structural characteristics of query results. Optionally, output format includes but is not limited to column selection and order, data type and format, sorting rules, grouping and aggregation, number of rows and columns in the result set, etc.

Specifically, we first need to identify the “targeted subtask” to be analyzed, which is a specific task unit in the entire process, with specific execution logic, input parameters, data processing range, and output format.

Then collect the statement parameters of the targeted subtask. This includes but is not limited to variable names, parameter values, parameter types, parameter attributes and other information. Traverse all other subtasks and collect the statement parameters of each subtask. Compare the statement parameters of the targeted subtask with the statement parameters of each other subtask one by one to determine the degree of match between the two in terms of name, value, type, attribute, etc. If the parameters of the two are completely consistent or there is a compatible relationship (matching can be achieved through conversion), it is considered that they are matched in terms of statement parameters. Record the matching results of the statement parameters of each other subtask and the targeted subtask, such as whether the match is successful or not, the degree of match, etc.

Secondly, clarify the data processing scope of the targeted subtask, including but not limited to the data set size, number of records, start and end indexes, numerical range, time range, spatial range, etc. Similarly, traverse all other subtasks and collect their respective data processing scope information. Compare the data range of the targeted subtask with the data range of each other subtask to determine whether there is overlap or complete consistency. If the data range of a subtask is completely contained in the range of the targeted subtask, or both process the same range of data, then the two subtasks are considered to match in terms of data range. Record the data range matching results of each other subtask and the targeted subtask.

Then define the output format of the targeted subtask, including but not limited to structured data formats (such as CSV, JSON, XML, etc.), unstructured data formats (such as text, images, audio and video, etc.), metadata specifications, API return formats, etc. Collect the output format information of all other subtasks. Compare the output format of the targeted subtask with the output format of each other subtask to determine whether the two are the same or whether they can be compatible through standardized conversion. If two subtasks can produce results that follow the same data model, encoding rules, and file standards, or these results can be replaced by each other, then the two subtasks are considered to match in output format. Record the output format matching results of each other subtask and the targeted subtask.

Then, based on all the matching results recorded in steps 2 to 4, each other subtask is comprehensively evaluated. If another subtask meets the requirements in parameter matching, range matching, and format matching (i.e., it is highly matched or completely consistent with the targeted subtask), or its execution logic is obviously dependent on the output of the targeted subtask (i.e., its input parameters, data range, and output format match the output of the targeted subtask), then this other subtask is considered to have a dependency relationship with the targeted subtask or have the same properties. All other subtasks that meet the above conditions are marked as "shared subtasks".

Finally, based on the identified shared subtasks, corresponding task optimization, resource sharing, code reuse, logic merging and other operations are performed to improve efficiency, reduce redundant calculations, simplify maintenance work, and achieve task collaboration and maximize resource utilization.

After identifying shared subtasks, the common code logic can be abstracted to form independent modules or services for multiple tasks to reuse. This not only reduces the amount of code and code complexity, but also simplifies maintenance and improves code quality and readability. At the same time, unified processing logic also helps ensure data consistency and reduce potential errors caused by repeated coding.

In one of the embodiments, a first target subtask set is screened out from other subtasks, the first target subtask set includes other subtasks that are determined based on parameter matching results and are consistent with the targeted subtasks in statement parameters; a second target subtask set is screened out from other subtasks, the second target subtask set includes other subtasks that are determined based on range matching results and are consistent with the targeted subtasks in data range; a third target subtask set is screened out from other subtasks, the third target subtask set includes other subtasks that are determined based on format matching results and are consistent with the targeted subtasks in output format; when there are other subtasks that exist in the first target subtask set, the second target subtask set and the third target subtask set at the same time, the targeted subtask is taken as a shared subtask.

Specifically, first clarify the specific task instance that is currently to be analyzed and judged as a shared subtask. Obtain all related subtasks except the targeted subtask to form an "other subtask" set. Clarify the key statement parameters that affect the execution of subtasks, such as query conditions, calculation parameters, function call parameters, etc. Compare the statement parameters of the targeted subtask with each subtask in the "other subtask" set item by item to determine whether they are completely consistent. Filter out other subtasks whose statement parameters are completely consistent with the targeted subtask to form the "first target subtask set".

Secondly, identify the factors that affect the data scope of the subtask processing, such as time interval, geographical area, specific record ID list, etc. Compare the data scope of the targeted subtask with each subtask in the "first target subtask set" item by item to determine whether they are completely consistent. Filter out the subtasks whose data scope is completely consistent with the targeted subtask from the "first target subtask set" to form the "second target subtask set".

Then, the format requirements of the subtask output results are clarified, such as data structure, file type, coding specification, report style, etc. The output format of the targeted subtask is compared item by item with each subtask in the "second target subtask set" to determine whether they are completely consistent. The subtasks whose output format is completely consistent with the targeted subtask are selected from the "second target subtask set" to form the "third target subtask set".

Finally, check whether the subtasks in the "third target subtask set" exist in the "first target subtask set", "second target subtask set" and "third target subtask set". If such subtasks exist, that is, they are consistent with the targeted subtask in terms of statement parameters, data range and output format, then the targeted subtask is determined to be a shared subtask.

By identifying other subtasks that are consistent with the targeted subtask in terms of statement parameters, data range, and output format, and judging whether the targeted subtask is qualified as a shared subtask, this method ensures that only when the key attributes are completely consistent can it be identified as a shared subtask, which is conducive to accurately identifying the parts that can be truly reused and processed collaboratively, and realizing effective resource utilization and performance improvement.

In one of the embodiments, a fourth target subtask set is screened out from other subtasks, the fourth target subtask set includes other subtasks that are determined based on parameter matching results and are partially consistent with the targeted subtasks in statement parameters; a fifth target subtask set is screened out from other subtasks of the fourth target subtask set, the fifth target subtask set includes other subtasks that are determined based on range matching results and are partially consistent with the targeted subtasks in data range; a sixth target subtask set is screened out from other subtasks of the fifth target subtask set, the sixth target subtask set includes other subtasks that are determined based on format matching results and are partially consistent with the targeted subtasks in output format; other subtasks existing in the sixth target subtask set are determined to be dependent on the targeted subtask, and the targeted subtask is used as a shared subtask.

Specifically, first clarify the specific task instance that is currently to be analyzed and judged as a shared subtask. Obtain all related subtasks except the targeted subtask to form an "other subtask" set. Clarify the key statement parameters that affect the execution of subtasks, such as query conditions, calculation parameters, function call parameters, etc. Compare the statement parameters of the targeted subtask with each subtask in the "other subtask" set item by item to determine whether there are partially consistent parameters (that is, at least some of the parameters are the same, but not necessarily all of the parameters are the same). Filter out other subtasks whose statement parameters are partially consistent with the targeted subtask to form the "fourth target subtask set."

Secondly, identify the factors that affect the data range of the subtask processing, such as time interval, geographical area, specific record ID list, etc. Compare the data range of the targeted subtask with each subtask in the "fourth target subtask set" item by item to determine whether there is a partially consistent range (that is, at least part of the data range is the same, but not necessarily all of the data range is the same). Filter out the subtasks whose data range is partially consistent with the targeted subtask from the "fourth target subtask set" to form the "fifth target subtask set".

Then, the format requirements of the subtask output results are clarified, such as data structure, file type, encoding specification, report style, etc. The output formats of the targeted subtasks are compared item by item with each subtask in the "fifth target subtask set" to determine whether there are partially consistent formats (that is, at least some format attributes are the same, but not necessarily all format attributes are the same). The subtasks whose output formats are partially consistent with the targeted subtasks are selected from the "fifth target subtask set" to form the "sixth target subtask set".

Finally, other subtasks in the "sixth target subtask set" are determined to be dependent on the targeted subtask, because these subtasks are partially consistent with the targeted subtask in terms of statement parameters, data range, and output format, indicating that they are dependent on the processing results or partial logic of the targeted subtask to some extent. Since there are other subtasks that depend on the targeted subtask, the targeted subtask is treated as a shared subtask. This means that the processing results or partial logic of the targeted subtask can be reused by other subtasks, which helps to reduce repeated calculations and improve resource utilization.

Since subtasks that are partially consistent with the targeted subtask in terms of statement parameters, data range, and output format are screened out from other subtasks, the dependency between them and the targeted subtask is determined, and the targeted subtask is treated as a shared subtask accordingly. This method allows a certain degree of flexibility, and even if the subtasks are not completely consistent, potential reuse opportunities can be identified, which helps to further explore the optimization potential.

In one of the embodiments, for each shared subtask, the target database query task to which the shared subtask belonged before being split is determined; the shared subtask is marked in the target database query task to which the shared subtask belonged before being split to obtain a marked task; for each marked database query task, the marked task and the shared subtask that belonged to the marked task before being split are assigned to the same idle thread.

Among them, marking tasks refers to the process of identifying and distinguishing a part of the original database query task (i.e., shared subtasks). When a complex database query task is split into multiple subtasks that are executed in parallel, in order to subsequently manage and schedule these subtasks, it is necessary to first clarify the original query task to which each subtask belongs before it is split, as well as its position and role in the task.

Specifically, for each shared subtask to be processed, first determine the target database query task to which it belongs before being split. For example, if a large query task is split into several subqueries, we need to know the position and role of each subquery in the original task. Then, after determining the original query task to which the shared subtask belongs, mark the subtask to form a "marked task". This step may include setting a specific identifier, tag or attribute for the subtask to record its relationship with the original query task to facilitate subsequent task scheduling and management. Then, after completing the marking of all shared subtasks, a series of subtasks with specific tags (i.e., marked tasks) will be formed. These marked tasks not only contain the content of the subtask itself, but also record their contextual information in the original query task. Finally, for each marked database query task (i.e., marked subtask), find an idle thread, and then assign this marked task and other shared subtasks in the original query task to which it belongs before being split to this thread for processing.

Due to the reasonable task splitting, marking and thread scheduling strategies, the query efficiency is improved, and the stability and scalability are enhanced. In addition, each subtask can be independently optimized according to its characteristics, and can be recombined according to the marking information when necessary, so as to flexibly respond to changes in query requirements in different scenarios.

In one of the embodiments, for each idle thread, the assigned shared subtask is processed by the targeted idle thread to obtain the shared subresult corresponding to the assigned shared subtask; the assigned marking task is processed by the targeted idle thread, and when the targeted idle thread processes the shared subtask in the assigned marking task, the shared subresult of the shared subtask that belonged to the assigned marking task before being split is used as the processing result of the shared subtask in the assigned marking task, and the post-marking database query task continues to be processed by the idle thread.

The shared sub-result refers to the intermediate result generated by each shared sub-task after being processed independently. Since the entire database query task is split into multiple shared sub-tasks, each sub-task runs on its own idle thread and completes part of the calculation. The result generated at this time is the "shared sub-result".

Specifically, firstly, all available idle thread resources are detected. A large or complex database query task is decomposed into multiple smaller, independently processable shared subtasks. Secondly, for each identified idle thread, one or more shared subtasks are assigned to it. The idle thread starts to execute the shared subtasks assigned to it, such as performing data retrieval or calculation operations within a specific range. After completing the processing, each idle thread will generate the result of the shared subtask it processes, that is, the "shared subresult". Then, in some cases, there may be specially marked tasks, which may also contain a series of related shared subtasks. When an idle thread encounters such a marked task, it will process the shared subtasks contained in the task in a targeted manner. Then, when the idle thread is processing a shared subtask in the marked task, if this subtask has been split and processed before, it should already have a calculated shared subresult. At this time, the idle thread will obtain the previous calculation result of the shared subtask that has been split and belongs to the current marked task, and directly use this result as the processing result of the current subtask. Finally, after obtaining the processing results of the corresponding shared subtasks, the idle thread will continue to process the remaining parts of the marking task, including but not limited to other unprocessed shared subtasks, and possible integration or aggregation work, until the entire database query task after marking is completed.

Even if the subtasks are executed independently on different threads, the use of marking and sharing subresults ensures that the results of each subtask are correctly integrated to obtain a complete query result. It is very suitable for processing large data volumes and high-complexity query scenarios, especially for real-time applications and large-scale data analysis that require fast response, and can provide significant performance improvements.

In one of the embodiments, after the idle thread has completed processing multiple target database query tasks and shared subtasks, the execution status of multiple target database query tasks in the preparation queue is switched from not yet executed to canceled; the number of supplementary tasks is determined based on the number of database query tasks with canceled status in the preparation queue; and the received number of supplementary tasks and the number of database query tasks are stored in the preparation queue.

The number of supplementary tasks refers to the number of new database query tasks that need to be added to the reserve queue after certain conditions are met.

Specifically, first, an idle thread is detected. The idle thread takes out multiple target database query tasks and related shared subtasks from the preparation queue for processing. The idle thread executes these tasks one by one until all target database query tasks and their shared subtasks have been successfully processed.

Then, when all the tasks assigned to the idle threads are completed, the status of these completed tasks in the standby queue will be switched from "not yet executed" to "cancelled", indicating that these tasks no longer need to be executed. For these completed target database query tasks and shared subtasks, the data management period can be set to automatically destroy them upon expiration to release memory. For subtasks that have not been executed, the data management period can also be set to automatically cancel them upon expiration. The dependent tasks related to the management of the subtask are also canceled, and an alarm notification is sent through webhook (a real-time communication method based on HTTP protocol).

Then check the number of tasks in the "cancelled" state in the preparation queue. According to this number and the preset rules or algorithms, determine how many new database query tasks need to be added to keep enough tasks in the queue for subsequent idle threads to process.

Finally, the number of additional tasks from external input or other task generation channels is received, and these new tasks are added to the preparation queue one by one, ready for execution by the next batch of idle threads.

By updating the status of tasks in real time (such as "not yet executed" to "cancelled"), the execution status of each task can be clearly tracked, which is convenient for monitoring and troubleshooting. Cancel the executed tasks to prevent repeated execution, saving computing resources and database access overhead. And dynamically determine the number of supplementary tasks based on the cancellation of tasks in the reserve queue to ensure that the task queue always has a certain amount of task reserves to maintain continuous operation and responsiveness. The automated task supplementation function enhances the self-recovery and expansion capabilities of the system, especially when facing a large number of short-term tasks, it can quickly adjust and adapt.

In an exemplary embodiment, as shown in FIG3 , steps 302 to 306 are included. Among them:

Step 302, determine the idle threads, if the number of idle threads exceeds the preset thread threshold, then determine the target screening number of database query tasks according to the number of idle threads; obtain the execution status information of each database query task in the preparatory task queue, and determine the database query tasks whose execution status information is not yet executed as candidate database query tasks; obtain the entry time of each candidate database query task in the preparatory task queue; in the order of entry time from far to near, sequentially select the target database query tasks with the target screening number from the multiple candidate database query tasks in the preparatory task queue; or obtain the query priority of each candidate database query task in the preparatory task queue; in the order of query priority from high to low, sequentially select the target database query tasks with the target screening number from the multiple candidate database query tasks in the preparatory task queue;

Step 304, split each target database query task into multiple subtasks;

Step 306, respectively matching the statement parameters of the targeted subtask with other subtasks to obtain parameter matching results; respectively matching the data range of the targeted subtask with other subtasks to obtain range matching results; respectively matching the output format of the targeted subtask with other subtasks to obtain format matching results; filtering out a first target subtask set from other subtasks, the first target subtask set including other subtasks that are consistent with the targeted subtask in statement parameters according to the parameter matching results; filtering out a second target subtask set from other subtasks, the second target subtask set including other subtasks that are consistent with the targeted subtask in data range according to the range matching results; filtering out a third target subtask set from other subtasks, the third target subtask set including other subtasks that are consistent with the targeted subtask in output format according to the format matching results; when there are other subtasks that exist in the first target subtask set, the second target subtask set and the third target subtask set at the same time, the targeted subtask is used as a shared subtask;

or

Match the statement parameters of the targeted subtask with other subtasks respectively to obtain parameter matching results; match the data range of the targeted subtask with other subtasks respectively to obtain range matching results; match the output format of the targeted subtask with other subtasks respectively to obtain format matching results; select a fourth target subtask set from other subtasks, the fourth target subtask set includes other subtasks that are determined according to the parameter matching results and are partially consistent with the targeted subtask in statement parameters; select a fifth target subtask set from other subtasks in the fourth target subtask set, the fifth target subtask set includes other subtasks that are determined according to the range matching results and are partially consistent with the targeted subtask in data range; select a sixth target subtask set from other subtasks in the fifth target subtask set, the sixth target subtask set includes other subtasks that are determined according to the format matching results and are partially consistent with the targeted subtask in output format; determine other subtasks in the sixth target subtask set as dependent on the targeted subtask, and use the targeted subtask as a shared subtask;

Step 308, for each shared subtask, determine the target database query task to which the shared subtask belongs before being split; mark the shared subtask in the target database query task to which the shared subtask belongs before being split to obtain a marked task; for each marked database query task, assign the marked task and the shared subtask that belonged to the marked task before being split to the same idle thread;

Step 310, for each idle thread, the assigned shared subtask is processed by the idle thread to obtain the shared subresult corresponding to the assigned shared subtask; the assigned marking task is processed by the idle thread, and when the idle thread processes the shared subtask in the assigned marking task, the shared subresult of the shared subtask that belonged to the assigned marking task before being split is used as the processing result of the shared subtask in the assigned marking task, and the post-marking database query task is continued to be processed by the idle thread;

Step 312, when the idle thread has completed processing the multiple target database query tasks and shared subtasks, the execution status of the multiple target database query tasks in the preparation queue is switched from not yet executed to canceled; the number of supplementary tasks is determined according to the number of database query tasks with canceled status in the preparation queue; and the number of database query tasks received, which is the number of supplementary tasks, is stored in the preparation queue.

It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

Based on the same inventive concept, the embodiment of the present application also provides a database query task asynchronous management device for implementing the database query task asynchronous management method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more database query task asynchronous management device embodiments provided below can refer to the limitations of the database query task asynchronous management method above, and will not be repeated here.

In an exemplary embodiment, as shown in FIG. 4 , a database query task asynchronous management device 400 is provided, comprising: a first determination module 402 , a splitting module 404 , a second determination module 406 and an allocation module 408 , wherein:

The first determination module 402 is used to determine idle threads, and if the number of idle threads exceeds a preset thread threshold, multiple target database query tasks are screened out from the preparation task queue according to the number of idle threads;

A splitting module 404 is used to split each target database query task into multiple subtasks;

A second determining module 406 is used for, for each of the multiple subtasks, if it is determined that other subtasks depend on the targeted subtask, or have other subtasks that are the same as the targeted subtask, then the targeted subtask is used as a shared subtask;

The allocation module 408 is used to allocate multiple target database query tasks and shared subtasks to idle threads for processing.

In one embodiment, the first determination module 402 is used to determine the target screening number of database query tasks based on the number of idle threads; obtain the execution status information of each database query task in the preparation task queue, and determine the database query tasks whose execution status information is not yet executed as candidate database query tasks; and filter out the target screening number of target database query tasks from the candidate database query tasks.

In one embodiment, the first determination module 402 is used to obtain the entry time of each candidate database query task in the preparation task queue; in order of the entry time from far to near, sequentially select the target database query tasks with a target screening number from the multiple candidate database query tasks in the preparation task queue; or obtain the query priority of each candidate database query task in the preparation task queue; in order of the query priority from high to low, sequentially select the target database query tasks with a target screening number from the multiple candidate database query tasks in the preparation task queue.

In one embodiment, the second determination module 406 is used to match the statement parameters of the targeted subtask with other subtasks to obtain parameter matching results; match the data range of the targeted subtask with other subtasks to obtain range matching results; match the output format of the targeted subtask with other subtasks to obtain format matching results; when it is determined based on the parameter matching results, the range matching results and the format matching results that other subtasks are dependent on the targeted subtask, or have other subtasks that are the same as the targeted subtask, the targeted subtask is used as a shared subtask.

In one embodiment, the second determination module 406 is used to filter out a first target subtask set from other subtasks, the first target subtask set including other subtasks determined based on parameter matching results and consistent with the targeted subtasks in statement parameters; filter out a second target subtask set from other subtasks, the second target subtask set including other subtasks determined based on range matching results and consistent with the targeted subtasks in data range; filter out a third target subtask set from other subtasks, the third target subtask set including other subtasks determined based on format matching results and consistent with the targeted subtasks in output format; when there are other subtasks that exist in the first target subtask set, the second target subtask set and the third target subtask set at the same time, the targeted subtask is used as a shared subtask.

In one embodiment, the second determination module 406 is used to filter out a fourth target subtask set from other subtasks, the fourth target subtask set including other subtasks that are determined based on parameter matching results and are partially consistent with the targeted subtasks in statement parameters; filter out a fifth target subtask set from other subtasks in the fourth target subtask set, the fifth target subtask set including other subtasks that are determined based on range matching results and are partially consistent with the targeted subtasks in data range; filter out a sixth target subtask set from other subtasks in the fifth target subtask set, the sixth target subtask set including other subtasks that are determined based on format matching results and are partially consistent with the targeted subtasks in output format; determine other subtasks existing in the sixth target subtask set as dependent on the targeted subtask, and treat the targeted subtask as a shared subtask.

In one embodiment, the allocation module 408 is used to determine, for each shared subtask, the target database query task to which the shared subtask belongs before being split; mark the shared subtask in the target database query task to which the shared subtask belongs before being split to obtain a marked task; and for each marked database query task, assign the marked task and the shared subtask that belonged to the marked task before being split to the same idle thread.

In one of the embodiments, the database query task asynchronous management device also includes a processing module 410, which is used to process the assigned shared subtask through the targeted idle thread for each idle thread to obtain the shared subresult corresponding to the assigned shared subtask; process the assigned marking task through the targeted idle thread, and when the targeted idle thread processes the shared subtask in the assigned marking task, the shared subresult of the shared subtask that belonged to the assigned marking task before being split is used as the processing result of the shared subtask in the assigned marking task, and continue to process the marked database query task through the idle thread.

In one embodiment, the database query task asynchronous management device also includes a supplement module 412, which is used to switch the execution status of multiple target database query tasks in the preparation queue from not yet executed to canceled when the idle thread completes processing of multiple target database query tasks and shared subtasks; determine the number of supplementary tasks based on the number of database query tasks with canceled status in the preparation queue; and store the received number of supplementary tasks, that is, database query tasks, in the preparation queue.

In another embodiment, as shown in FIG5 , FIG5 is a structural block diagram of a database query task asynchronous management device in another embodiment, including: a first determination module 402, a splitting module 404, a second determination module 406 and an allocation module 408. Among them, the database query task asynchronous management device 400 also includes a processing module 410 and a supplementing module 412. The processing module 140 is used for processing the allocated shared subtasks through the idle threads for each idle thread to obtain the shared subresults corresponding to the allocated shared subtasks; processing the allocated marking tasks through the idle threads, when the idle threads process the shared subtasks in the allocated marking tasks, the shared subresults of the shared subtasks that belonged to the allocated marking tasks before being split are used as the processing results of the shared subtasks in the allocated marking tasks, and the marked database query tasks are continued to be processed through the idle threads. The supplement module 412 is used to switch the execution status of multiple target database query tasks in the preparation queue from not yet executed to canceled after the idle thread has processed multiple target database query tasks and shared subtasks; determine the number of supplementary tasks based on the number of database query tasks with canceled status in the preparation queue; and store the received number of supplementary tasks, that is, database query tasks, in the preparation queue.

Each module in the above-mentioned database query task asynchronous management device can be implemented in whole or in part by software, hardware and their combination. Each module can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in FIG6. The computer device includes a processor, a memory, an input/output interface (Input/Output, referred to as I/O) and a communication interface. The processor, the memory and the input/output interface are connected via a bus, and the communication interface is connected to the bus via the input/output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores operations, computer programs and databases. The internal memory provides an environment for the operation of the operations and computer programs in the non-volatile storage medium. The database of the computer device is used to store data related to asynchronous management of database query tasks. The input/output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a method for asynchronous management of database query tasks is implemented.

Those skilled in the art will understand that the structure shown in FIG. 6 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

The technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims (13)

1. An asynchronous management method for database query tasks, the method comprising:

Determining idle threads, and screening a plurality of target database query tasks from a preparation task queue according to the number of the idle threads if the number of the idle threads exceeds a preset thread threshold;

Splitting each target database query task into a plurality of subtasks;

For each of the plurality of subtasks, if it is determined that other subtasks depend on the subtask being targeted, or have other subtasks that are the same as the subtask being targeted, then the subtask being targeted is taken as a shared subtask;

And distributing the target database query tasks and the sharing subtasks to the idle thread for processing.

2. The method of claim 1, wherein the screening the preliminary task queue for a plurality of target database query tasks based on the number of idle threads comprises:

determining the target screening number of database query tasks according to the number of idle threads;

acquiring the execution state information of each database query task in the preparation task queue, and determining the database query task which is not executed yet as the execution state information as a candidate database query task;

And screening a plurality of target database query tasks for the target screening from the candidate database query tasks.

3. The method of claim 2, wherein said screening the number of target database query tasks for the target from the candidate database query tasks comprises:

acquiring the enqueuing time of each candidate database query task in the preparation task queue;

Sequentially screening target database query tasks with the number being the target screening number from a plurality of candidate database query tasks in the preparation task queue according to the sequence of the listing time from far to near;

or acquiring the query priority of each candidate database query task in the preparation task queue;

and sequentially screening target database query tasks with the number of target screening numbers from a plurality of candidate database query tasks in the preparation task queue according to the order of the query priority from high to low.

4. The method of claim 1, wherein for each of the plurality of subtasks, if it is determined that other subtasks depend on the subtask being targeted, or have other subtasks that are the same as the subtask being targeted, then treating the subtask being targeted as a shared subtask comprises:

respectively carrying out sentence parameter matching on the subtasks and other subtasks to obtain parameter matching results;

respectively carrying out data range matching on the subtasks and other subtasks to obtain range matching results;

respectively carrying out output format matching on the subtasks and other subtasks to obtain a format matching result;

And when determining that other subtasks depend on the subtasks aimed or have other subtasks identical to the subtasks aimed according to the parameter matching result, the range matching result and the format matching result, taking the subtasks aimed as shared subtasks.

5. The method of claim 4, wherein upon determining that there are other subtasks that are the same as the subtasks being targeted based on the parameter matching result, the range matching result, and the format matching result, then taking the subtasks being targeted as shared subtasks comprises:

screening a first target subtask set from other subtasks, wherein the first target subtask set comprises other subtasks which are determined according to the parameter matching result and keep consistent with the subtasks in terms of statement parameters;

screening a second target subtask set from other subtasks, wherein the second target subtask set comprises other subtasks which are determined according to the range matching result and keep consistent with the subtasks in the data range;

screening a third target subtask set from other subtasks, wherein the third target subtask set comprises other subtasks which are determined according to the format matching result and keep consistent with the subtasks in the output format;

and when other subtasks exist in the first target subtask set, the second target subtask set and the third target subtask set at the same time, the subtask to be targeted is used as a sharing subtask.

6. The method of claim 4, wherein when it is determined that other subtasks depend on the subtask being targeted based on the parameter matching result, the range matching result, and the format matching result, then taking the subtask being targeted as a shared subtask comprises:

Screening a fourth target subtask set from other subtasks, wherein the fourth target subtask set comprises other subtasks which are determined according to the parameter matching result and are kept partially consistent with the subtasks in statement parameters;

Screening a fifth target subtask set from other subtasks of the fourth target subtask set, wherein the fifth target subtask set comprises other subtasks which are determined according to the range matching result and are kept partially consistent with the subtasks in the data range;

screening a sixth target subtask set from other subtasks of the fifth target subtask set, wherein the sixth target subtask set comprises other subtasks which are determined according to the format matching result and are partially consistent with the subtasks in the output format;

other subtasks present in the sixth target set of subtasks are determined to be dependent on the subtask being directed and the subtask being directed is taken as a shared subtask.

7. The method of claim 1, wherein assigning the plurality of target database query tasks and the shared subtask to the idle thread for processing comprises:

For each shared subtask, determining a target database query task to which the shared subtask to which the target database query task belongs before being split;

Marking the aimed sharing subtasks in the target database query task which the aimed sharing subtasks belong to before being split, so as to obtain marking tasks;

For each marked database query task, the marked task aimed at and the shared subtask belonging to the marked task aimed at before being split are distributed to the same idle thread.

8. The method of claim 7, wherein the method further comprises:

Aiming at each idle thread, processing the assigned sharing subtasks through the aimed idle thread to obtain a sharing subtask corresponding to the assigned sharing subtask;

And processing the distributed marking tasks through the aimed idle threads, when the aimed idle threads process the shared subtasks in the distributed marking tasks, taking the shared subtasks which are assigned to the distributed marking tasks before being split as the processing results of the shared subtasks in the distributed marking tasks, and continuously processing the marked database query tasks through the idle threads.

9. The method according to claim 1, wherein the method further comprises:

after the idle thread finishes processing the target database query tasks and the sharing subtasks, switching the execution state of the target database query tasks in the preparation queue from not-executed to cancelled;

Determining the number of supplementary tasks according to the number of database query tasks with cancellation states in the preparation queue;

and storing the received number of the supplementary tasks into the preparation queue.

10. An asynchronous management device for database query tasks, the device comprising:

The first determining module is used for determining idle threads, and if the number of the idle threads exceeds a preset thread threshold value, screening a plurality of target database query tasks from a preparation task queue according to the number of the idle threads;

The splitting module is used for splitting each target database query task into a plurality of subtasks;

A second determining module, configured to, for each of the plurality of subtasks, take the subtask that is targeted as a shared subtask if it is determined that other subtasks depend on the subtask that is targeted, or have other subtasks that are the same as the subtask that is targeted;

And the distribution module is used for distributing the target database query tasks and the sharing subtasks to the idle threads for processing.

11. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any one of claims 1 to 9 when the computer program is executed.

12. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 9.

13. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any one of claims 1 to 9.