Hybrid load scheduling method based on SQL fingerprints

Abstract

The embodiment of the invention provides a hybrid load scheduling method based on SQL fingerprints, and the method comprises the steps: receiving a to-be-processed SQL statement, and determining a first SQL fingerprint corresponding to the to-be-processed SQL statement; determining a target thread classification category of the first SQL fingerprint according to the first SQL fingerprint and an SQL fingerprint classification table; and processing the to-be-processed SQL statement according to the target thread classification category and a pre-allocated execution thread resource to obtain a target processing result corresponding to the to-be-processed SQL statement. The continuity of online transaction processing execution and the stability of delay are improved, the operation and maintenance efficiency is improved, and the system stability is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of computer system application technology, and in particular to a hybrid load scheduling method based on SQL fingerprints. Background Technology

[0002] In mixed database workload scenarios, the system needs to simultaneously support low-latency, high-concurrency Online Transactional Processing (OLTP) and resource-intensive Online Analytical Processing (OLAP). Because OLAP operations involve large-scale data scanning and complex calculations, they consume significant amounts of shared resources such as Central Processing Unit (CPU), memory pools, and I / O bandwidth. Long-running OLAP operations may result in prolonged holding of system-level locks or mutexes, increasing OLTP transaction wait times.

[0003] Existing concurrency control mechanisms manage parallelism through resource quotas and priority configurations. Their scheduling decisions rely solely on superficial characteristics such as join attributes or transaction durations, lacking the ability to identify statement execution complexity using Structured Query Language (SQL) fingerprints. This scheduling approach struggles to achieve accurate resource allocation in mixed load scenarios, preventing OLTP workloads from adaptively adjusting execution plans and necessitating manual intervention for optimization. This not only increases human resource and time costs but also causes response delays, impacting business continuity. Summary of the Invention

[0004] This invention provides a hybrid load scheduling method based on SQL fingerprints to achieve resource scheduling and adaptive adjustment of OLTP execution plans in hybrid load scenarios.

[0005] In a first aspect, embodiments of the present invention provide a hybrid load scheduling method based on SQL fingerprints, comprising:

[0006] Receive the SQL statement to be processed and determine the first SQL fingerprint corresponding to the SQL statement to be processed;

[0007] Based on the first SQL fingerprint and the SQL fingerprint classification table, determine the target thread classification category of the first SQL fingerprint;

[0008] Based on the target thread classification and the pre-allocated execution thread resources, the SQL statement to be processed is processed to obtain the target processing result corresponding to the SQL statement to be processed.

[0009] Secondly, embodiments of the present invention provide a hybrid load scheduling device based on SQL fingerprints, comprising:

[0010] The first SQL fingerprint determination module is used to receive the SQL statement to be processed and determine the first SQL fingerprint corresponding to the SQL statement to be processed.

[0011] The classification category determination module is used to determine the target thread classification category of the first SQL fingerprint based on the first SQL fingerprint and the SQL fingerprint classification table;

[0012] The target processing result determination module is used to process the SQL statement to be processed according to the target thread classification category and the pre-allocated execution thread resources to obtain the target processing result corresponding to the SQL statement to be processed.

[0013] Thirdly, embodiments of the present invention also provide an electronic device, comprising:

[0014] At least one processor; and

[0015] A memory that is communicatively connected to at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor can execute a hybrid load scheduling method based on SQL fingerprints as provided in any embodiment of the present invention.

[0017] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions for causing a processor to execute a hybrid load scheduling method based on SQL fingerprints as provided in any embodiment of the present invention.

[0018] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements a hybrid load scheduling method based on SQL fingerprints as described in any of the embodiments of this disclosure.

[0019] The technical solution provided in this invention, after receiving an SQL statement to be processed, determines a first SQL fingerprint corresponding to the SQL statement; obtains an SQL fingerprint classification table, and determines the target thread classification category of the first SQL fingerprint based on the first SQL fingerprint and the SQL fingerprint classification table. Execution thread resources are allocated based on the target thread classification category corresponding to the SQL statement to be processed. Further, the SQL statement to be processed is processed according to the target thread classification category and the pre-allocated execution thread resources. Finally, the target processing result corresponding to the SQL statement to be processed is obtained. This achieves resource isolation between OLTP and OLAP loads in mixed load scenarios by routing different categories of SQL statements to isolated thread resource pools, improving the continuity of OLTP execution and the stability of latency.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart of a hybrid load scheduling method based on SQL fingerprints provided in an embodiment of the present invention;

[0023] Figure 2 A schematic diagram of a hybrid load scheduling method based on SQL fingerprinting provided in an embodiment of the present invention;

[0024] Figure 3 A flowchart of a hybrid load scheduling method based on SQL fingerprints provided in an embodiment of the present invention;

[0025] Figure 4 A schematic diagram of a hybrid load scheduling device based on SQL fingerprinting provided in an embodiment of the present invention;

[0026] Figure 5 This is a schematic diagram of an electronic device for a hybrid load scheduling method based on SQL fingerprints, provided in an embodiment of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] Before introducing the technical solutions provided in the embodiments of this disclosure, the application scenarios can be illustrated first. In a high-performance database architecture, the system needs to support two types of core business simultaneously: OLTP workloads and OLAP workloads. OLTP workloads are real-time data processing workloads for daily business transaction scenarios, requiring rapid response to high-frequency transaction requests, such as inventory deduction and order payment operations. OLAP workloads are batch data processing workloads for data statistical analysis scenarios. They are used for complex aggregation and multi-table joins on massive amounts of data, such as backend sales analysis, user behavior mining, and real-time dashboard queries. In traditional architectures, long-running OLAP operations consume a large amount of shared resources such as CPU resources, memory pools, and I / O bandwidth, thereby increasing the waiting time for high-concurrency OLTP operations.

[0030] Figure 1 This invention provides a flowchart of a hybrid load scheduling method based on SQL fingerprints, applicable to resource scheduling and adaptive adjustment of execution plans in hybrid load scenarios. The method can be executed by a hybrid load scheduling device based on SQL fingerprints, which can be implemented in hardware and / or software and configured in a computing device. Figure 1 As shown, the method includes:

[0031] S110. Receive the SQL statement to be processed and determine the first SQL fingerprint corresponding to the SQL statement to be processed.

[0032] The SQL statement to be processed can be a newly submitted SQL command from the database client to the database server that has not yet been executed. The SQL statement to be processed is the raw, unprocessed statement. An SQL fingerprint can be a unique identifier generated after standardization and normalization. One SQL fingerprint can represent a class of SQL statements with the same structure. The standardization process may include, but is not limited to, removing spaces, comments, replacing parameter literals with placeholders, and standardizing case.

[0033] This can be understood as follows: upon receiving the SQL statement to be processed, the pre-processor initiates a standardization process. The SQL statement is standardized and normalized to generate a first SQL fingerprint corresponding to it. This first SQL fingerprint can be used as one of the decision data for subsequent classification.

[0034] S120. Determine the target thread classification category of the first SQL fingerprint based on the first SQL fingerprint and the SQL fingerprint classification table.

[0035] The SQL fingerprint classification table can be a core metadata table maintained internally by the database system. This table uses the SQL fingerprint as the primary key and stores the associated attributes for known SQL statements. These associated attributes may include, but are not limited to, thread classification, last evaluation time, evaluation confidence level, and performance baseline metrics.

[0036] The thread classification category can be the type determination result corresponding to the SQL fingerprint. In this embodiment, the thread classification category can include OLTP classification category, OLAP classification category, and unknown classification category.

[0037] The most recent evaluation time can be the moment when the classification information of the SQL statement was last updated, which can be used to trigger a re-evaluation of SQL statements that may have undergone performance changes.

[0038] The confidence level can be used to assess the degree of certainty that the system classifies a thread. A high confidence level indicates a high probability that the SQL fingerprint belongs to that thread category.

[0039] In this embodiment, to improve the execution quality of OLTP services, the execution of OLTP services is optimized. Therefore, the performance baseline metric can be the historical P95 latency for OLTP queries. The historical P95 latency records the 95th percentile latency value of the SQL statement within a preset period. When the actual execution latency of the SQL statement consistently exceeds this historical P95 latency metric, the system considers it to have experienced performance degradation.

[0040] The target thread category can be the thread category corresponding to the first SQL fingerprint. The target thread category corresponding to the first SQL fingerprint is determined according to the SQL fingerprint classification table. For example, there are three target thread categories: OLTP category, OLAP category, and unknown category.

[0041] This can be understood as obtaining the first SQL fingerprint corresponding to the SQL statement to be processed. Using the first SQL fingerprint as the query key, a matching search is performed in the SQL fingerprint classification table. If a record corresponding to the first SQL fingerprint is found in the SQL fingerprint classification table, a preset thread classification field is read from that record; this thread classification category is the target thread classification category corresponding to the first SQL fingerprint. If no record related to the first SQL fingerprint is found in the SQL fingerprint classification table, the corresponding target thread classification category is set to an unknown classification category.

[0042] S130. Based on the target thread classification category and the pre-allocated execution thread resources, process the SQL statement to be processed to obtain the target processing result corresponding to the SQL statement to be processed.

[0043] The pre-allocated execution thread resources can be runtime resource pools bound to the target thread category. Execution thread resources typically include, but are not limited to, dedicated thread groups. At system startup, the thread pool manager physically isolates three execution thread groups. These three different categories of execution thread groups include OLTP execution thread groups, OLAP execution thread groups, and unknown SQL execution thread groups. The target processing result can be the result generated after the SQL statement is finally executed.

[0044] Different execution thread resources are allocated based on the target thread classification. These execution thread resources include OLTP execution thread groups, OLAP execution thread groups, and unknown category execution thread groups. For example, the OLTP execution thread group is dedicated to handling requests classified as OLTP, targeting high-concurrency and low-latency scenarios, and receives 70% of the total thread resources. The OLAP execution thread group is dedicated to handling requests classified as OLAP, meeting the needs of batch data analysis, and receives 20% of the total thread resources. The unknown category execution thread group is used to handle SQL statements that cannot be immediately classified or appear for the first time, serving as the sandbox environment for the workload assessment module, and receives 10% of the total thread resources. It should be noted that the scheduling priority of the unknown category execution thread group is higher than that of the OLAP group.

[0045] It should be noted that the thread pool manager manages the maximum number of active queries for each execution thread through at least one preset parameter. These preset parameters include the proportion of OLTP execution thread groups to the total number of threads, the proportion of OLAP execution thread groups to the total number of thread groups, the maximum allowed concurrent active queries for an OLTP group, the preset execution count, the minimum cooldown time after SQL fingerprint migration, and a preset proportion range.

[0046] This can be understood as follows: First, obtain the target thread category corresponding to the first SQL fingerprint and determine the pre-allocated execution thread resources. Then, based on the target thread category and the pre-allocated execution thread resources, process the SQL statement to be processed. Finally, obtain the target processing result corresponding to the SQL statement to be processed.

[0047] Considering the cyclical fluctuations in actual business load, such as significant differences in resource configurations for peak daytime transaction periods and batch report generation tasks at night, resource adjustments can be made to execution thread resources to improve resource utilization and meet dynamic business requirements. Optionally, other methods include:

[0048] When a resource adjustment operation corresponding to the execution thread resource is received, the execution thread resource is re-determined based on the thread resource allocation ratio corresponding to the resource adjustment operation.

[0049] Execution thread resources can refer to physical thread resources that have been allocated to threads that are not currently in use during database runtime. Resource adjustment operations can be operations that adjust the thread resource allocation ratio. This operation is typically initiated by an administrator or automated operation and maintenance system. The thread resource allocation ratio can be the proportion of the system's total computing resources distributed among various worker threads.

[0050] For example, database administrators can adjust the thread resource allocation ratio based on nighttime maintenance windows or seasonal load changes.

[0051] This can be understood as the database administrator issuing an instruction to adjust the resource allocation for execution threads. Upon receiving the instruction, the thread resource allocation ratio is readjusted, and the execution thread resources are determined based on the corresponding thread resource allocation ratio. This enables the database to have online resource management capabilities, improves resource utilization, and ensures maximum resource utilization.

[0052] The technical solution provided by this invention involves, upon receiving an SQL statement to be processed, determining a first SQL fingerprint corresponding to the SQL statement; obtaining an SQL fingerprint classification table; and determining the target thread category of the first SQL fingerprint based on the first SQL fingerprint and the SQL fingerprint classification table. Execution thread resources are then allocated based on the target thread category corresponding to the SQL statement to be processed. Furthermore, the SQL statement to be processed is processed according to the target thread category and the pre-allocated execution thread resources. Finally, the target processing result corresponding to the SQL statement to be processed is obtained. This achieves resource isolation between OLTP and OLAP loads in mixed load scenarios by routing different categories of SQL statements to isolated thread resource pools. It improves the continuity of OLTP execution and the stability of latency, enhances operational efficiency, and ensures system stability.

[0053] Figure 2 This is a schematic diagram of a hybrid load scheduling method based on SQL fingerprints provided in an embodiment of the present invention. When the target thread category corresponding to the SQL statement to be processed is a preset category, the target thread category of the SQL statement to be processed needs to be further determined. Based on the foregoing embodiments, this embodiment elaborates in detail the process of determining the category of the SQL statement to be processed when the target thread category is a preset category.

[0054] like Figure 2 As shown, the method includes:

[0055] S210. When the target thread category is a preset category, the SQL statement to be processed is executed repeatedly based on the execution thread resources corresponding to the preset category.

[0056] In this embodiment, the preset category is usually an unknown category in the pre-set thread category.

[0057] This can be understood as follows: when the target thread category corresponding to the SQL statement to be processed is a preset category, the SQL statement to be processed is repeatedly executed according to the execution thread resources corresponding to the preset category, and the number of executions can be a preset number of executions.

[0058] S220. Based on the execution results of multiple repeated executions, determine the first category result of the SQL statement to be processed.

[0059] The execution results can be multi-dimensional performance metrics collected after each repeated execution, such as execution time, CPU consumption, and memory usage. The first classification result can be the final thread category to which the SQL statement to be processed belongs, determined by the system based on the execution result data.

[0060] This can be understood as repeatedly executing the SQL statement to be processed multiple times based on the corresponding execution thread resources, obtaining multiple execution results. Based on these multiple execution results, the first category result of the SQL statement to be processed is determined.

[0061] Optionally, the preset classification category is an unknown category, and the first classification result is either the online transaction processing category or the online analysis and processing category.

[0062] It should be noted that if the preset classification category is unknown, the SQL statement to be processed needs to be executed multiple times based on the corresponding execution thread resources. The execution results from these multiple executions are then obtained, and the first classification result determined based on these results can be either an OLTP classification category or an OLAP classification category.

[0063] Furthermore, when the target thread category is a preset category, the SQL statement to be processed is repeatedly executed multiple times based on the execution thread resources corresponding to the preset category. Next, the process of determining the first category result is described in detail. Optionally, the first category result of the SQL statement to be processed is determined based on the execution results of the multiple repeated executions, including:

[0064] Based on the number of logical reads, memory allocation, and operator type in the execution plan of each execution result, the execution volume information of the SQL statement to be processed is determined; the execution volume information is analyzed based on the load assessment module to determine the second classification result corresponding to the execution volume information and the corresponding confidence level to be processed; based on the second classification result and the corresponding confidence level to be processed corresponding to multiple execution results, the first classification result and confidence level of the SQL statement to be processed are determined.

[0065] In this embodiment, the SQL statement to be processed is repeatedly executed based on the corresponding execution thread resources, and the execution results corresponding to the multiple executions are obtained. The execution results are then used to obtain the logical read count, memory allocation, and operator type of the execution plan. The logical read count is the number of data blocks read from the memory buffer during SQL execution, representing the data access volume and caching efficiency. The memory allocation is the amount of memory occupied during SQL execution, reflecting computational complexity. The operator type of the execution plan can be the type of basic operation unit in the database execution engine, such as full table scan, Cartesian product, large-scale hash join, or aggregation operation. It can be noted that OLTP is biased towards index-based point lookups, while OLAP is biased towards full scans and complex joins.

[0066] For example, if the operator type is a full table scan, Cartesian product, or large-scale hash join or aggregation operation, the SQL to be processed is more likely to be OLAP.

[0067] The execution volume information can be data obtained by quantifying the execution results, which is used to input into the load assessment module to evaluate the category. The load assessment module can be a module used to determine the specific category of the SQL statement to be processed for which the category is unknown.

[0068] Furthermore, the process of classifying the SQL statement to be processed based on the load assessment module is explained. The execution results from multiple executions are obtained. These results are then integrated into execution volume information corresponding to the SQL statement to be processed. The execution volume information of the SQL statement to be processed is compared with known OLTP / OLAP patterns, ultimately providing a second classification result and corresponding confidence score for each individual execution result. The second classification result can be the classification result given by the load assessment module after analyzing a single execution. The confidence score is the reliability score corresponding to this classification result, representing the degree of matching between this execution and the classified category. The confidence score is the reliability score corresponding to the first classification result determined based on multiple execution results.

[0069] Specifically, the logical read count, memory allocation, and operator type of the execution plan are obtained from multiple repeated execution results, and this data is integrated into the execution volume information of the SQL statement to be processed. The execution volume information is analyzed by the load assessment module to obtain the second category result and the corresponding confidence level for each execution result. Further, the second category results and corresponding confidence levels for multiple execution results are obtained, and the confidence level for each execution result is used as a weight. The weights of the results in the same category are summed to obtain the total weight score for that category. The category with the highest total weight score is taken as the first category result, and the proportion of its total weight score to the total weight score of all categories is used as the confidence level.

[0070] S230. Update the SQL fingerprint classification table based on the first classification result and the first SQL fingerprint of the SQL statement to be processed.

[0071] This can be understood as follows: once the first classification result and corresponding first SQL fingerprint of the SQL statement to be processed are determined, the SQL fingerprint classification table is updated. Using the SQL fingerprint as the primary key, a new row is created containing the first classification result, the most recent evaluation time, and the evaluation confidence level. For the classified OLTP statement, performance metrics such as the execution latency are used as initial values ​​to fill the key performance limit indicator field, completing the initial registration of the SQL statement in the system.

[0072] The technical solution provided by this invention involves repeatedly executing the SQL statement to be processed multiple times based on the execution thread resources corresponding to the preset classification category when the target thread classification category is a preset classification category. Further, based on the execution results of the multiple repeated executions, a first classification result for the SQL statement to be processed is determined. The SQL fingerprint classification table is then updated based on the first classification result and the first SQL fingerprint of the SQL statement to be processed, completing the initial registration of the SQL statement to be processed in the system. By automatically classifying and evaluating SQL statements to be processed that have not undergone classification evaluation, the system can continuously improve and update the SQL fingerprint classification table. This allows for continuous performance monitoring of OLTP workloads based on the SQL fingerprint classification table, ensuring OLTP business continuity and response stability, and improving the reliability of the database system.

[0073] Figure 3 This document presents a flowchart of a hybrid load scheduling method based on SQL fingerprinting, provided as an embodiment of the present invention. Building upon the aforementioned embodiments, it detects and maintains all processed SQL statements categorized as OLTP for all target threads. The maintenance process for these processed SQL statements is described in detail, based on the aforementioned embodiments. Figure 3 As shown, the method includes:

[0074] S310. For at least a portion of the processed SQL statements whose target thread classification is online transaction processing, calculate the total time consumption information corresponding to the processed SQL statements, and determine the baseline time consumption information and the SQL statements to be maintained based on a portion of the total time consumption information.

[0075] Among them, the SQL statements to be maintained are the SQL statements that have already been processed.

[0076] In this embodiment, the total execution time information can be a set of execution time information for at least a portion of the processed SQL statements belonging to the OLTP category for each target thread, obtained by the system within a preset period. The preset period can be a pre-set monitoring period. The baseline execution time information can be the optimal execution time information achieved under stable operating conditions within the preset period, representing the performance upper limit of the SQL under ideal resource and data conditions. For example, all P95 latency values ​​corresponding to a SQL statement within the preset period are obtained, and the optimal P95 latency value achieved within the preset period is obtained from them, and the optimal P95 latency value is used as the baseline execution time information. The SQL statements to be maintained can be processed SQL statements belonging to the OLTP category for target threads whose actual execution time is longer than the baseline execution time information, selected by comparing the total execution time information with the calculated baseline execution time information.

[0077] This can be understood as retrieving processed SQL statements for target threads categorized as OLTP. The system collects the total processing time information for processed SQL statements within a preset period. Furthermore, it determines the baseline processing time information for all processed SQL statements across all OLTP categories within this preset period.

[0078] Specifically, the system continuously collects total time consumption information for SQL fingerprints for each OLTP category. It periodically analyzes and calculates from the total time consumption information, updates the baseline time consumption information, and finally determines the SQL statements to be maintained and their corresponding baseline time consumption information.

[0079] S320. Based on the total time consumption information and baseline time consumption information of the SQL statement to be maintained, determine whether the SQL statement to be maintained is the target SQL statement to be maintained.

[0080] Among them, the target maintenance SQL statement can be the SQL statement that needs to be optimized by comparing the total time consumption information and the baseline time consumption information in the set of statements to be maintained.

[0081] Specifically, obtain the total time and baseline time information for all SQL statements to be maintained. Compare the baseline time information of each SQL statement to be maintained with the total time information. Select the SQL statements to be maintained as target SQL statements according to preset judgment rules.

[0082] Furthermore, preset judgment rules are used to filter the SQL statements to be maintained, identifying those that require execution plan optimization. The specific filtering method for the SQL statements to be maintained is described in detail below. Optionally, based on the total time consumption information and baseline time consumption information of the SQL statement to be maintained, it is determined whether the SQL statement to be maintained is the target maintenance SQL statement, including:

[0083] When the total time spent by the SQL statement to be maintained exceeds the preset proportion of the baseline time spent, the SQL statement to be maintained is identified as the target SQL statement to be maintained.

[0084] Here, "multiple periods" can be understood as obtaining multiple total time consumption information for the SQL statements to be maintained within multiple monitoring periods, and the number of periods can be set by the user. "Preset ratio range" can be understood as a pre-set upper limit for percentage fluctuation relative to the baseline.

[0085] This can be understood as obtaining the total time consumption information and baseline time consumption information of the SQL statement to be maintained over multiple periods. A judgment threshold is determined based on the baseline time consumption information and a preset ratio range. The total time consumption information for each period is compared with the judgment threshold sequentially, and the number of times the total time consumption information exceeds the judgment threshold is recorded. When the preset threshold for the number of times the total time consumption exceeds the threshold is reached, the SQL statement to be maintained can be determined as the target SQL statement.

[0086] For example, the number of cycles is set to 3, the preset ratio range is 120%, and the preset threshold for exceeding the limit is 2 times. A SQL statement to be maintained is obtained, along with its total time consumption over the three cycles and the corresponding baseline time consumption. The baseline time consumption is multiplied by the preset ratio range to obtain the judgment threshold. The three total time consumption values ​​for the three cycles are compared with the corresponding judgment threshold. If the total time consumption exceeds the judgment threshold 3 times, the SQL statement to be maintained is determined to be the target SQL statement for maintenance.

[0087] Furthermore, after obtaining the target maintenance SQL statement, further analysis is conducted to identify the root cause of performance degradation and eliminate interference caused by external environmental factors.

[0088] To eliminate external interference, further investigation is needed to determine the cause of performance degradation in the target maintenance SQL statements. Optionally, other methods may include:

[0089] When the total time spent on the target maintenance SQL statement corresponds to a preset wait event type, retrieve the degradation information associated with the wait event type; when the total time spent on the target maintenance SQL statement corresponds to an internal wait event type, manage the execution plan corresponding to the target maintenance SQL statement.

[0090] The preset wait event type is a predefined and standardized wait state classification in the database, used to indicate the reason for SQL execution blocking. In this embodiment, the preset wait event type can be an external wait event.

[0091] External wait events are waiting states that arise when the database execution engine is processing SQL and needs to rely on resources or coordination mechanisms outside the database. External wait events include, but are not limited to, lock waits, log write synchronization waits, and physical I / O waits. Lock waits occur when a database session attempts to access a data resource that is already locked by another session. Log write synchronization waits occur when the database commits a transaction and needs to ensure the redo log is written to disk before returning a success confirmation to the client; during this period, the relevant sessions must wait. Physical I / O waits occur when the data page needed by the database is not in the memory buffer and must be read from the physical disk into memory.

[0092] It can be explained that the process of corresponding preset wait event types to the total time consumption information of the target maintenance SQL statement is as follows: The total time consumption information of the target maintenance SQL statement is obtained, and the proportion of the time consumption information of each wait event of the target maintenance SQL statement to the total time consumption information is calculated. When the proportion of the time consumption information of the preset wait event type is greater than the preset judgment threshold, it is determined that the performance degradation is due to external resource bottlenecks or transaction conflicts. The preset judgment threshold is pre-set and used to determine the wait event type of the target maintenance SQL statement.

[0093] Degradation information refers to contextual data automatically collected by the system when SQL performance experiences waiting issues. In this embodiment, degradation information associated with the wait type is typically related to external wait events. This can be understood as automatically querying relevant performance views and metadata based on external wait events to obtain the contextual data for the wait. Degradation information may include, but is not limited to, basic event statistics, session-level correlation information, and system resource correlation information.

[0094] When the total execution time of the target maintenance SQL statement determines it to be an internal wait event, the execution plan corresponding to that statement is managed. An internal wait event can be understood as SQL performance degradation stemming from CPU computation and memory access, rather than external resource waiting. The execution plan corresponding to the target maintenance SQL statement is the actual execution plan used by that SQL in the current database state. Managing the execution plan can be understood as implementing full lifecycle control over the execution plan, such as capturing, analyzing, and repairing it.

[0095] After identifying the target maintenance SQL statement, the type of wait event is determined based on the total execution time of the target maintenance SQL statement. A preset threshold is established for initial determination of the wait event type. When the proportion of the execution time of the preset wait event in the total execution time of the target maintenance SQL statement exceeds the preset threshold, it is determined to be a preset wait event type, and the degradation information associated with the wait event type is retrieved. If the proportion of the execution time of the internal wait event in the total execution time of the target maintenance SQL statement exceeds the preset threshold, and further judgment is performed, it is determined to be an internal wait event, and the execution plan corresponding to the target maintenance SQL statement is adjusted. The proportion of wait events in the total execution time determines whether the wait event type of the target maintenance SQL statement is an external or internal wait event. This can rule out situations where performance degradation originates from external resource bottlenecks or transaction conflicts, and avoids activation of execution plan management due to external hardware failures or lock contention errors.

[0096] When the proportion of time-consuming information for a preset waiting event type exceeds a preset judgment threshold, it can be preliminarily determined to be an internal waiting event type. After preliminary determination, further judgment is required. Optionally, the internal waiting event type is determined based on at least one of the following methods:

[0097] The CPU consumption information is greater than or equal to the preset consumption information threshold; the number of logical reads is greater than or equal to the preset number of reads threshold; the execution plan complexity of the target maintenance SQL statement does not meet the preset conditions.

[0098] The CPU consumption information refers to the resource consumption information of the CPU during SQL execution. This CPU consumption information is compared with a preset consumption threshold, which is a pre-defined threshold for judging CPU consumption. Logical read counts are the total number of times data blocks are read from the database buffer cache during SQL execution. The preset read count threshold is a pre-defined threshold for judging the number of cache read data blocks. Execution plan complexity is an indicator that measures the structural complexity and computational intensity of the execution plan, characterizing the complexity of the SQL data processing path. The preset condition is a pre-defined standard threshold for execution plan complexity.

[0099] This can be understood as follows: after initially identifying an internal wait event, further judgment is made. Information such as CPU consumption, logical read counts, and execution plan complexity is obtained. If the CPU consumption is greater than or equal to a preset consumption threshold, the logical read count is greater than or equal to a preset count threshold, and the execution plan complexity of the target SQL statement does not meet preset conditions, then the performance degradation is ultimately determined to be due to increased internal execution time. Setting multiple thresholds further clarifies the internal wait event type, improving judgment accuracy and execution plan management success rate.

[0100] Furthermore, after determining that the total execution time of the target maintenance SQL statement corresponds to the internal wait event type, the execution plan corresponding to the target maintenance SQL statement is managed to ensure OLTP latency stability. Optionally, the management of the execution plan corresponding to the target maintenance SQL statement includes:

[0101] Based on the SQL fingerprint of the target maintenance SQL statement, the system reads the historical execution plans used within the historical period and determines the optimal execution plan based on the complexity of the historical execution plans. If the optimal execution plan is valid, it is associated with the target maintenance SQL statement so that the optimal execution plan corresponding to the target maintenance SQL statement can be retrieved when the target maintenance SQL statement is received again. If the optimal execution plan is invalid, the optimizer optimizes the parameters of the execution plan currently used by the target maintenance SQL statement and verifies the optimized execution plan by calling the execution thread resources corresponding to the target thread category. If the verification is successful, the optimized execution plan is associated with the target maintenance SQL statement.

[0102] The historical period can be a preset historical event window used to obtain the execution plan of SQL within a historical event. The historical execution plan used within the historical period can be the set of all execution plans actually used by SQL within the historical period. The optimal execution plan is determined based on the complexity of the historical execution plans. The optimal execution plan is the best execution plan selected based on complexity.

[0103] Once historical execution plans from the past period are obtained, their structural complexity, computational complexity, data access complexity, and resource consumption complexity can be evaluated. Structural complexity includes, but is not limited to, the number of operation steps, nesting depth, join complexity, and branching complexity; computational complexity includes, but is not limited to, sorting operations, aggregation calculations, and data transformations; data access complexity may include, but is not limited to, temporary space usage, index efficiency, and partition access; and resource consumption complexity includes, but is not limited to, memory requirements and CPU consumption. A score is obtained for each dimension, and a complexity score is derived based on each dimension's score and preset weights. Finally, the optimal execution plan is determined by obtaining the complexity score for each historical execution plan.

[0104] Furthermore, after obtaining the optimal execution plan, its validity is determined. For example, this involves checking the integrity of the indexes relied upon by the historical execution plan and ensuring that the table structure definition has not changed. If the indexes are intact and the table structure remains unchanged, the optimal execution plan is considered valid; otherwise, it is deemed invalid, meaning the optimal execution plan cannot be executed correctly or achieve the expected performance metrics in the current database environment.

[0105] When the optimal execution plan becomes ineffective, the optimizer optimizes the parameters of the current execution plan used by the target SQL statement. The optimizer is the query optimization component of the database kernel, a decision engine used to analyze SQL statements and generate the optimal execution plan. Parameter optimization based on the optimizer can be understood as adjusting the currently used execution plan to generate a new, lower-cost execution plan.

[0106] After obtaining the new execution plan, the execution thread resource corresponding to the target thread category is invoked to verify the optimized execution plan. In this embodiment, the target thread category is an unknown category. The optimized execution plan is a newly generated low-cost execution plan. The verification process involves executing tests in a controlled, isolated environment. It is confirmed that the optimized execution plan achieves the expected results, and no further execution plan management is required.

[0107] Specifically, based on the SQL fingerprint corresponding to the target maintenance SQL statement, historical execution plans used within the historical period are read. The complexity of the historical execution plans is calculated, and the best execution plan among them is determined. Furthermore, the best execution plan is verified to determine its effectiveness. If the best execution plan is effective, it is automatically bound to the target maintenance SQL statement via the database interface; if the best execution plan is invalid, an optimized execution plan is generated using forced parameters based on the optimizer. To ensure executability, the execution thread resources corresponding to the target thread category are invoked to perform sandbox verification on the optimized execution plan. If the optimized execution plan passes verification, it is automatically bound to the target maintenance SQL statement via the database interface. This automated management and optimization of execution plans improves the degree of operational automation and reduces the time and resource consumption of manual tuning and execution plan binding by database administrators.

[0108] Furthermore, to prevent bound execution plans from becoming invalid over time, the system can periodically perform automatic verification of the bound execution plans. This involves calling the execution thread resources corresponding to the target thread category to verify the plans and test for the existence of better execution plans resulting from updates to statistics or changes in the index structure. If the test results indicate the existence of a better execution plan, then the bound plan is replaced. Through continuous adaptive optimization, operational efficiency and system stability are improved.

[0109] The technical solution provided in this invention, to ensure the latency stability of OLTP, involves statistically analyzing the total time consumption of at least a portion of the processed SQL statements that fall under the OLTP category of the target thread. Based on a portion of the total time consumption information, baseline time consumption and the SQL statement to be maintained are determined. Furthermore, the total time consumption of the SQL statement to be maintained is compared with the baseline time consumption to determine whether the SQL statement to be maintained is the target SQL statement, so that the execution plan corresponding to the target SQL statement can be optimized and managed subsequently. Continuous monitoring of the OLTP thread group ensures OLTP execution and improves OLTP latency stability.

[0110] Figure 4 A schematic diagram of a hybrid load scheduling device based on SQL fingerprinting provided in an embodiment of the present invention is shown below. Figure 4 As shown, the device includes: a first SQL fingerprint determination module 410, a classification category determination module 420, and a target processing result determination module 430.

[0111] The first SQL fingerprint determination module 410 is used to receive the SQL statement to be processed and determine the first SQL fingerprint corresponding to the SQL statement to be processed; the classification category determination module 420 is used to determine the target thread classification category of the first SQL fingerprint according to the first SQL fingerprint and the SQL fingerprint classification table; the target processing result determination module 430 is used to process the SQL statement to be processed according to the target thread classification category and the pre-allocated execution thread resources to obtain the target processing result corresponding to the SQL statement to be processed.

[0112] The technical solution provided in this invention, after receiving an SQL statement to be processed, determines a first SQL fingerprint corresponding to the SQL statement; obtains an SQL fingerprint classification table, and determines the target thread classification category of the first SQL fingerprint based on the first SQL fingerprint and the SQL fingerprint classification table. Execution thread resources are allocated based on the target thread classification category corresponding to the SQL statement to be processed. Further, the SQL statement to be processed is processed according to the target thread classification category and the pre-allocated execution thread resources. Finally, the target processing result corresponding to the SQL statement to be processed is obtained. This achieves resource isolation between OLTP and OLAP loads in mixed load scenarios by routing different categories of SQL statements to isolated thread resource pools, improving the continuity of OLTP execution and the stability of latency.

[0113] Based on the above technical solutions, the device further includes:

[0114] The SQL statement execution module is used to repeatedly execute the SQL statement to be processed multiple times based on the execution thread resources corresponding to the preset category when the target thread category is a preset category.

[0115] The first classification result determination module is used to determine the first classification result of the SQL statement to be processed based on the execution results of multiple repeated executions.

[0116] The SQL fingerprint classification table update module is used to update the SQL fingerprint classification table based on the first classification result and the first SQL fingerprint of the SQL statement to be processed.

[0117] Based on the above technical solutions, the preset classification category is an unknown classification category, and the first classification result is an OLTP classification category or an OLAP classification category.

[0118] Based on the above technical solutions, the first classification result determination module includes:

[0119] The execution volume information determination unit is used to determine the execution volume information of the SQL statement to be processed based on the number of logical reads, memory allocation, and operator type in the execution plan of each execution result.

[0120] The second classification result determination unit is used to analyze the execution volume information based on the load assessment module, and determine the second classification result corresponding to the execution volume information and the corresponding confidence level to be processed.

[0121] The first classification result determination unit is used to determine the first classification result and confidence level of the SQL statement to be processed based on the second classification result corresponding to the multiple execution results and the corresponding confidence level to be processed.

[0122] Based on the above technical solutions, the device further includes:

[0123] The module for determining SQL statements to be maintained is used to, for at least a portion of the processed SQL statements belonging to the OLTP category of the target thread, to calculate the total time consumption information corresponding to the processed SQL statements, and to determine the baseline time consumption information and the SQL statements to be maintained based on a portion of the total time consumption information; wherein, the SQL statements to be maintained are the processed SQL statements.

[0124] The target maintenance SQL statement determination module is used to determine whether the SQL statement to be maintained is a target maintenance SQL statement based on the total time consumption information of the SQL statement to be maintained and the baseline time consumption information.

[0125] Based on the above technical solutions, the target maintenance SQL statement determination module includes:

[0126] The target maintenance SQL statement determination unit is used to determine the SQL statement to be maintained as the target maintenance SQL statement when the total time consumption information of the SQL statement to be maintained in multiple periods exceeds a preset proportion range of the baseline time consumption information.

[0127] Based on the above technical solutions, the device further includes:

[0128] The degradation information retrieval module is used to retrieve degradation information associated with the waiting event type when the total time consumption information of the target maintenance SQL statement corresponds to a preset waiting event type.

[0129] The execution plan management module is used to manage the execution plan corresponding to the target maintenance SQL statement when the total time information of the target maintenance SQL statement corresponds to an internal wait event type.

[0130] Based on the above technical solutions, the internal waiting event type is determined based on at least one of the following methods: the CPU consumption information is greater than or equal to a preset consumption information threshold; the number of logical reads is greater than or equal to a preset number threshold; the execution plan complexity of the target maintenance SQL statement does not meet a preset condition.

[0131] Based on the above technical solutions, the execution plan management module includes:

[0132] The optimal execution plan determination unit is used to determine the optimal execution plan based on the historical execution plans used in the SQL fingerprint reading history period of the target maintained SQL statement and the complexity of the historical execution plans.

[0133] The optimal execution plan retrieval unit is used to associate the optimal execution plan with the target maintenance SQL statement when the optimal execution plan is valid, so as to retrieve the optimal execution plan corresponding to the target maintenance SQL statement when the target maintenance SQL statement is received again.

[0134] The execution plan association unit is used to optimize the parameters of the execution plan currently used by the target maintenance SQL statement based on the optimizer when the best execution plan is invalid, and to verify the optimized execution plan by calling the execution thread resources corresponding to the target thread category, so as to associate the optimized execution plan with the target maintenance SQL statement when the verification is successful.

[0135] Based on the above technical solutions, the device further includes:

[0136] The execution thread resource determination module is used to redetermine the execution thread resource based on the thread resource allocation ratio corresponding to the resource adjustment operation when a resource adjustment operation corresponding to the execution thread resource is received.

[0137] The SQL fingerprint-based hybrid load scheduling device provided in this embodiment of the invention can execute a SQL fingerprint-based hybrid load scheduling method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0138] Figure 5 This is a schematic diagram of an electronic device for an embodiment of the present invention providing a hybrid load scheduling method based on SQL fingerprints. The electronic device is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0139] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0140] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0141] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a hybrid load scheduling method based on SQL fingerprints.

[0142] In some embodiments, a hybrid load scheduling method based on SQL fingerprints can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the hybrid load scheduling method based on SQL fingerprints described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute a hybrid load scheduling method based on SQL fingerprints by any other suitable means (e.g., by means of firmware).

[0143] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0144] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0145] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0146] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0147] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0148] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0149] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0150] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A hybrid load scheduling method based on SQL fingerprinting, characterized in that, include: Receive the SQL statement to be processed and determine the first SQL fingerprint corresponding to the SQL statement to be processed; Based on the first SQL fingerprint and the SQL fingerprint classification table, determine the target thread classification category of the first SQL fingerprint; Based on the target thread classification and the pre-allocated execution thread resources, the SQL statement to be processed is processed to obtain the target processing result corresponding to the SQL statement to be processed.

2. The method according to claim 1, characterized in that, The method further includes: When the target thread category is a preset category, the SQL statement to be processed is executed repeatedly based on the execution thread resources corresponding to the preset category. Based on the execution results of multiple repeated executions, determine the first category result of the SQL statement to be processed; The SQL fingerprint classification table is updated based on the first classification result and the first SQL fingerprint of the SQL statement to be processed.

3. The method according to claim 1 or 2, characterized in that, The preset classification category is an unknown classification category, and the first classification result is either an online transaction processing classification category or an online analysis and processing classification category.

4. The method according to claim 2, characterized in that, The step of determining the first classification result of the SQL statement to be processed based on the execution results of multiple repeated executions includes: Based on the number of logical reads, memory allocation, and operator type in the execution plan of each execution result, determine the execution volume information for the SQL statement to be processed; The execution volume information is analyzed based on the load assessment module to determine the second classification result corresponding to the execution volume information and the corresponding confidence level to be processed. Based on the second classification results corresponding to the multiple execution results and the corresponding confidence scores to be processed, the first classification result and confidence score of the SQL statement to be processed are determined.

5. The method according to claim 1, characterized in that, The method further includes: For at least a portion of the processed SQL statements whose target thread classification is online transaction processing, the total time consumption information corresponding to the processed SQL statements is statistically analyzed, and based on a portion of the total time consumption information, baseline time consumption information and SQL statements to be maintained are determined; wherein, the SQL statements to be maintained are the processed SQL statements. Based on the total time consumption information of the SQL statement to be maintained and the baseline time consumption information, determine whether the SQL statement to be maintained is the target SQL statement to be maintained.

6. The method according to claim 5, characterized in that, The step of determining whether the SQL statement to be maintained is the target SQL statement to be maintained based on the total time consumption information of the SQL statement to be maintained and the baseline time consumption information includes: When the total time spent by the SQL statement to be maintained over multiple periods exceeds a preset proportion of the baseline time spent, the SQL statement to be maintained is determined to be the target SQL statement to be maintained.

7. The method according to claim 5, characterized in that, The method further includes: When the total time spent on the target maintenance SQL statement corresponds to a preset wait event type, retrieve the degradation information associated with the wait event type; When the total time consumption information of the target maintenance SQL statement corresponds to an internal wait event type, the execution plan corresponding to the target maintenance SQL statement is managed.

8. The method according to claim 7, characterized in that, The type of internal waiting event is determined based on at least one of the following methods: The CPU's power consumption is greater than or equal to a preset power consumption threshold. The number of logical reads is greater than or equal to the preset threshold. The execution plan complexity of the target maintenance SQL statement does not meet the preset conditions.

9. The method according to claim 7, characterized in that, The management of the execution plan corresponding to the target maintenance SQL statement includes: Based on the target, the SQL fingerprint of the SQL statement is read to determine the historical execution plan used within the historical period, and the optimal execution plan is determined according to the complexity of the historical execution plan. If the optimal execution plan is valid, the optimal execution plan is associated with the target maintenance SQL statement so that the optimal execution plan corresponding to the target maintenance SQL statement can be retrieved when the target maintenance SQL statement is received again. If the optimal execution plan is invalid, the optimizer optimizes the parameters of the current execution plan used by the target maintenance SQL statement, and verifies the optimized execution plan by calling the execution thread resource corresponding to the target thread category. If the verification is successful, the optimized execution plan is associated with the target maintenance SQL statement.

10. The method according to claim 1, characterized in that, The method further includes: Upon receiving a resource adjustment operation corresponding to the execution thread resource, the execution thread resource is re-determined based on the thread resource allocation ratio corresponding to the resource adjustment operation.

Images