A database slow SQL root cause automatic positioning method, device and medium

Abstract

The application discloses a kind of database slow SQL root cause automatic positioning method, equipment and medium, belong to database technical field, for solving in the root cause positioning of existing database slow SQL, the root cause of single dimension diagnosis is not complete, lack of feature fusion mechanism, cannot perceive the historical change of execution plan Technical problems.Method includes: when detecting database slow SQL data state, the multi-dimensional feature data of target SQL is collected;Multi-dimensional feature data in the acquisition completion state is carried out feature vector construction and normalization processing;Multi-dimensional structure feature vector is processed to the root cause classification of root cause classification decision tree, and based on the root cause confidence, the root cause type list sorted by confidence is output;Each root cause type in root cause type list is matched with root cause treatment template;Based on the treatment suggestion matched by searching strategy and root cause treatment template, generate slow SQL root cause diagnosis report.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a method, device and medium for automatically locating the root cause of slow SQL queries in a database. Background Technology

[0002] Slow SQL queries are the most common type of performance failure in production environments. The root causes of slow SQL queries typically fall into the following categories: Index-related: missing indexes, index invalidation (implicit type conversion, function-overriding columns), incorrect index selection; Statistics-related: outdated table / column statistics causing the optimizer to choose a suboptimal execution plan; Lock-related: row locks, table locks, intention locks, etc., leading to excessively long SQL execution queue times; Resource contention-related: bottlenecks in system resources such as CPU, I / O, and memory causing slow SQL execution; Execution plan mutation-related: changes in the SQL execution plan due to data volume variations, parameter sniffing, etc., causing a sharp drop in performance.

[0003] Existing databases (such as PostgreSQL, MySQL, and Oracle) provide basic capabilities for diagnosing slow SQL queries, including: slow query log, execution plan (EXPLAIN / EXPLAIN ANALYZE), wait events (waitevents), and system views (pg_stat_activity, performance_schema).

[0004] However, in database operations and maintenance scenarios, slow SQL (SQL statements whose execution time exceeds a threshold) is one of the core issues affecting business performance. When a slow SQL alert is triggered, operations and maintenance personnel need to quickly locate the root cause and take appropriate measures. In other words, there are still methods for locating the root cause of slow SQL in databases: 1. The root causes of slow SQL are complex and diverse (index failure, statistical information deviation, lock wait, resource contention, execution plan mutation, etc.), and a single-dimensional detection method cannot cover all root cause types; 2. The combination patterns of features in each dimension differ under different root causes, and there is a lack of a systematic feature fusion and root cause classification mechanism; 3. Existing tools only provide raw diagnostic data (such as execution plans and waiting events), which requires operations and maintenance personnel to manually correlate and analyze the data, resulting in low diagnostic efficiency and reliance on expert experience; 4. Unable to automatically output root cause conclusions and handling suggestions when slow SQL occurs, resulting in a long alarm response chain. Summary of the Invention

[0005] This application provides a method, device, and medium for automatically locating the root cause of slow SQL queries in databases, which solves the following technical problem: In the existing root cause location of slow SQL queries in databases, the root cause coverage of single-dimensional diagnosis is incomplete, there is a lack of feature fusion mechanism, and it is impossible to perceive the historical changes of the execution plan.

[0006] The embodiments of this application adopt the following technical solutions: On one hand, this application provides an automatic method for locating the root causes of slow SQL queries in a database, comprising: when a slow SQL query is detected in the database, collecting multidimensional feature data of the target SQL query; wherein the multidimensional feature data includes: execution plan features, statistical information features, lock wait features, resource indicator features, and historical comparison features of the execution plan; constructing and normalizing feature vectors from the multidimensional feature data in the completed collection state to obtain multidimensional structural feature vectors; performing root cause classification processing on the multidimensional structural feature vectors using a root cause classification decision tree, and outputting a root cause type list sorted by confidence based on multi-root cause confidence; performing root cause treatment template matching processing on each root cause type in the root cause type list, and obtaining a search strategy based on the scope of influence of the root cause type based on a list of other SQL queries affected by the same root cause type; and generating a slow SQL root cause diagnosis report based on the treatment suggestions matched by the search strategy and the root cause treatment template.

[0007] This application's embodiments, through multi-dimensional feature data, overcome the limitations of traditional single-dimensional diagnostics. They can capture slow SQL problems caused by multiple factors such as execution plan mutations, outdated statistics, lock contention, resource bottlenecks, or plan regression, effectively avoiding missed diagnoses and misdiagnoses from a single perspective, making root cause localization more complete and reliable. Furthermore, based on the introduced historical execution plan comparison features, it endows root cause diagnosis with dynamic time-dimensional perception capabilities, accurately identifying plan degradation problems caused by optimizer decision bias, bind variable snooping, and delayed statistical information updates. It also employs a decision tree model to classify the multi-dimensional structured feature vectors into root causes and outputs a list of root cause types sorted in descending order of confidence. This provides a quantitative ranking of confidence levels when multiple potential causes exist, assisting operations personnel in prioritizing the most likely causes while not overlooking suboptimal candidates, effectively balancing diagnostic accuracy and recall. It can also provide information on the specific repair actions for slow SQL queries and predict in advance other business SQL queries that may be affected by the root cause, thereby supporting batch processing, impact assessment, and pre-change risk assessment, significantly reducing the workload of repetitive diagnosis and lowering the probability of secondary problems caused by local repairs.

[0008] In one feasible implementation, when a slow SQL data state is detected in the database, multi-dimensional feature data of the target SQL is collected. Specifically, this includes: when a slow SQL data state is detected, extracting key features of the target SQL to obtain the execution plan features; wherein, the key features of the plan include: scan node type, row count estimation deviation rate of each node, proportion of actual time consumed by each node to the total execution time, sorting overflow, and hash join memory overflow; based on the tables and columns involved in the target SQL, querying the database system view to extract and obtain the statistical information features; wherein, the statistical information features include: statistical information freshness, data change volume, and high frequency. The deviation between the number of duplicate values ​​and the actual value in the column, as well as the abnormal proportion of null values, are analyzed. Lock wait characteristics are collected and obtained by querying the database's wait events and lock views. These lock wait characteristics include: the lock wait state of the target SQL during execution, the duration and type of the lock wait, the source and duration of the lock-holding transaction, and the depth of the lock wait chain. Within the slow SQL execution time window, the resource indicator characteristics of the host where the data resides are collected. Based on the execution plan snapshots periodically persisted by high-frequency SQL, the database SQL version triggered by the slow SQL is compared with the historical database SQL version, and the root cause of plan mutations is identified. The historical comparison characteristics of the execution plan are collected and determined.

[0009] In one feasible implementation, the database SQL version at the time of slow SQL triggering is compared with the historical database SQL version to identify the root cause of the plan mutation. The historical comparison features of the execution plan are collected and determined. Specifically, before collecting and determining the historical comparison features of the execution plan, SQL texts with the same logic but different versions are normalized, and the normalized SQL texts are then subjected to parameter placeholder replacement processing under relevant regular expressions to obtain replaced SQL texts. Based on the replaced SQL texts, the corresponding hash value is calculated, and a unique fingerprint identifier is generated for the replaced SQL texts. Using the unique fingerprint identifier as the primary key, the execution plan snapshot, historical performance data, and root cause diagnosis records of the current SQL are associated. Based on the execution plan results... The structural changes involve calculating the hash value of the relevant strings for the structural fields of each node in the execution plan structure to obtain the execution plan structure hash; and constructing an execution plan snapshot table based on the execution plan structure hash and the unique fingerprint identifier; wherein, the execution plan snapshot table also includes: an auto-incrementing primary key, a database instance identifier, the complete execution plan JSON original text, an execution plan summary, a snapshot collection time, an average execution time, and the number of sampled SQL executions corresponding to the execution plan snapshot; through the execution plan snapshot table, when a slow SQL data state is detected in the database, the current execution plan snapshot table of the current execution plan snapshot is compared and diagnosed with the historical execution plan snapshot table of the historical execution plan snapshots to output the historical comparison features of the execution plan.

[0010] In one feasible implementation, when a slow SQL data state is detected in the database, the multidimensional feature data of the target SQL is collected, which further includes: after the slow SQL is triggered for detection, the multidimensional feature data is processed by a concurrent collection coordinator to perform concurrent collection processing based on the timeout limit difference of each dimension feature; the missing dimension features in the multidimensional feature data are detected and processed, and the missing feature items corresponding to the missing dimension features are marked; based on different missing dimension features and the corresponding missing feature items, a missing processing strategy is executed to obtain the missing dimension features; wherein, the missing processing strategy is a decision tree execution strategy for each missing dimension feature; if there are more than three missing dimension features, the collection strategy of the multidimensional feature data is switched to a manual collection strategy, and the collection failure information of the missing dimension features is output.

[0011] In one feasible implementation, the multidimensional feature data in the completed acquisition state is subjected to feature vector construction and normalization processing to obtain a multidimensional structural feature vector. Specifically, this includes: extracting the corresponding features of each feature item in the multidimensional feature data according to a preset feature extraction rule, and converting the extracted feature items into structured features to obtain the multidimensional structural feature vector; wherein, each feature item includes: feature number, feature name, value type and description.

[0012] In one feasible implementation, the multidimensional structural feature vector is subjected to root cause classification processing using a root cause classification decision tree, and a root cause type list sorted by confidence is output based on multiple root cause confidence levels. Specifically, this includes: using the root cause classification decision tree, the multidimensional structural feature vector is subjected to a threshold judgment of combined feature terms based on root cause generation conditions to obtain root cause types and the root cause confidence level corresponding to each root cause type; wherein, the combined feature terms are all associated feature terms included in the root cause generation conditions; when the root cause classification decision tree determines multiple root cause branches and they are triggered simultaneously, the root cause confidence level corresponding to each root cause type after triggering is normalized; all normalized root cause confidence levels are sorted in descending order to generate a root cause type list sorted by confidence level; wherein, the root cause type list contains multiple candidate root causes, and the root cause type at the top of the root cause type list is the primary root cause.

[0013] In one feasible implementation, each root cause type in the root cause type list is matched with a root cause treatment template, and a search strategy based on the influence range of the root cause type is obtained based on the list of other SQL statements affected by the same root cause type. Specifically, this includes: using the root cause treatment template, recommending treatment measures for each root cause type in the root cause type list to obtain treatment suggestions; generating root cause labels based on the root cause type and the corresponding root cause confidence; generating key evidence based on the feature values ​​that trigger root cause judgment and the comparison values ​​of abnormal thresholds in the root cause classification decision tree; querying other SQL statements that share the same root cause type with the current slow SQL statement according to the diffusion dimensions of different root cause types to determine the list of other SQL statements affected by the same root cause type, and generating the search strategy based on the influence range of the root cause type; wherein the shared same root cause type includes: lock wait, execution plan mutation, statistical information deviation, missing or invalid index, and resource contention.

[0014] In one feasible implementation, a slow SQL root cause diagnostic report is generated based on the treatment suggestions obtained by matching the search strategy with the root cause treatment template. Specifically, this includes: based on the unique fingerprint identifier of the list of other SQLs affected by the same root cause type, aggregating the information of the corresponding related SQL template text, the average execution time and number of calls of the related SQLs in the current time window, and the judgment criteria for sharing a root cause with the current slow SQL, to obtain the scope of influence result; and generating the slow SQL root cause diagnostic report based on the scope of influence result, the search strategy, the key evidence, the root cause label, and the treatment suggestions.

[0015] Secondly, embodiments of this application also provide an automatic database slow SQL root cause localization device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to execute an automatic database slow SQL root cause localization method as described in any of the above embodiments.

[0016] Thirdly, embodiments of this application also provide a non-volatile computer storage medium, which is a non-volatile computer-readable storage medium storing at least one program. Each program includes instructions, which, when executed by a terminal, cause the terminal to execute a database slow SQL root cause automatic location method as described in any of the above embodiments.

[0017] This application provides a method, device, and medium for automatically locating the root causes of slow SQL queries in databases. Compared with the prior art, the embodiments of this application have the following beneficial technical effects: 1. By using multidimensional feature data, it is possible to capture slow SQL problems caused by multiple factors such as execution plan mutations, outdated statistics, lock contention, resource bottlenecks, or plan regression, effectively avoiding missed diagnoses and misdiagnoses from a single perspective, making the root cause localization range more complete and reliable.

[0018] 2. By introducing historical comparison features of execution plans, the root cause diagnosis is given dynamic perception capabilities in the time dimension. This overcomes the shortcomings of traditional static diagnosis, which relies solely on the current execution plan, and can accurately identify plan degradation problems caused by optimizer decision bias, binding variable snooping, and lag in statistical information updates.

[0019] 3. By using feature vectorization and normalization, the interference of scale differences between features on subsequent classification decisions is eliminated, and high-quality and stable input data is provided for the root cause classification decision tree, thereby improving the numerical robustness and reproducibility of root cause discrimination.

[0020] 4. A decision tree model is used to classify the root causes of multidimensional structural feature vectors and output a list of root cause types in descending order of confidence. When there are multiple potential causes, a quantitative ranking of confidence levels is provided to help maintenance personnel prioritize the investigation of the most likely causes, while not omitting the second-best candidates, effectively balancing the accuracy and recall of diagnosis.

[0021] 5. For each type of root cause in the output, the corresponding handling template is automatically matched, and combined with the list of other SQLs affected by the same root cause, the operation and maintenance personnel can not only know the specific repair actions for the current slow SQL, but also predict in advance other business SQLs that may be affected by the root cause. This supports batch handling, impact assessment and pre-change risk assessment, greatly reducing the workload of repetitive diagnosis and reducing the probability of secondary problems caused by partial repair. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart of an automatic root cause localization method for slow SQL queries in a database, provided in an embodiment of this application; Figure 2 A flowchart of an automatic root cause localization method for slow SQL queries in a database based on multi-dimensional feature fusion is provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an automatic root cause localization device for slow SQL queries in a database, provided as an embodiment of this application. Detailed Implementation

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

[0024] It should be noted that existing slow SQL detection and diagnosis methods for databases still have certain shortcomings: 1) Single-dimensional diagnosis, incomplete root cause coverage. Existing solutions each rely on a single data source (execution plan or wait event). Since the root causes of slow SQL are diverse, a single dimension cannot cover all scenarios. For example, when the execution plan is normal but lock waits exist, the execution plan analysis method cannot identify it; when the wait event is "CPU", it is impossible to determine whether the full table scan is caused by statistical information deviation or index failure, resulting in high CPU consumption.

[0025] 2) Lack of feature fusion mechanism, unable to automatically output root cause conclusions. Existing tools only provide raw data display and lack a mechanism to correlate and fuse multi-dimensional features and map them to specific root cause classifications. Operations personnel need to manually correlate data across multiple systems / views, and the diagnostic process relies on personal experience, resulting in a high misjudgment rate and low efficiency.

[0026] 3) Inability to detect historical changes in execution plans, leading to missed root causes of plan mutations. Execution plan mutations are an important type of root cause, but existing tools can only display the current execution plan and cannot compare it with historical plans. Therefore, they cannot identify the root cause that "the performance of a certain SQL query suddenly drops because the execution plan has changed."

[0027] 4) Diagnostic results are not actionable, and the response chain is long. Existing tools output charts or log data but do not provide handling suggestions. After obtaining the diagnostic data, maintenance personnel still need to perform secondary analysis before taking action, resulting in long alarm response times.

[0028] This application provides an embodiment of a method for automatically locating the root cause of slow SQL queries in a database, such as... Figure 1 As shown, the automatic root cause localization method for slow SQL queries in databases specifically includes steps S101-S105: S101. When a slow SQL data state is detected in the database, collect multi-dimensional feature data of the target SQL. This multi-dimensional feature data includes: execution plan features, statistical information features, lock wait features, resource indicator features, and historical comparison features of the execution plan.

[0029] Specifically, when a slow SQL query is detected in the database (execution time exceeds a preset threshold, or the diagnosis is manually triggered by operations personnel), the key features of the target SQL query are extracted to obtain the execution plan features. These key features include: scan node type, row count estimation deviation rate for each node, the proportion of actual execution time for each node to the total execution time, sorting overflow, and hash join memory overflow.

[0030] In one embodiment, during execution plan feature collection, it is necessary to execute EXPLAIN(ANALYZE, BUFFERS, FORMAT JSON) on the target SQL and extract the following key features: scan node type (Seq Scan / Index Scan / Bitmap Heap Scan, etc.); the ratio of actual rows to estimated rows for each node (row count estimation deviation rate); the proportion of actual time for each node to the total execution time; whether there is a sorting overflow (Sort Method: external merge); and whether there is a hash join memory overflow (Batches>1).

[0031] Furthermore, based on the tables and columns involved in the target SQL, the database system view is queried to extract and obtain statistical information features. These statistical information features include: statistical information freshness, data change volume, deviation between the number of duplicate values ​​and the actual values ​​of high-frequency columns, and abnormal proportion of null values.

[0032] In one embodiment, during the collection of statistical information features, it is necessary to query database system views (such as pg_stat_user_tables and pg_stats in PostgreSQL) for the tables and columns involved in the SQL, and extract the following features: the time interval between last_analyze and the current time for each table (statistical information freshness); n_mod_since_analyze (data change volume) for each table since the last analysis; the deviation between n_distinct (number of duplicate values) and the actual value for high-frequency columns; and whether there is an abnormal proportion of null values ​​(null_frac mutation).

[0033] Furthermore, it is necessary to collect and obtain lock wait characteristics by querying the database's wait events and lock views. These lock wait characteristics include: the lock wait state of the target SQL during execution, the duration and type of the lock wait, the source and duration of the lock-holding transaction, and the depth of the lock wait chain.

[0034] In one embodiment, during lock wait feature collection, the following features need to be collected by querying database wait events and lock views (such as pg_locks, pg_stat_activity): whether the target SQL is in a lock wait state during execution (wait_event_type='Lock'); the duration of the lock wait and the lock type (row lock / table lock / intent lock); the source of the lock-holding transaction and the duration of the lock holding; and the depth of the lock wait chain (whether there is a lock chain wait).

[0035] Furthermore, within the slow SQL execution time window, resource metrics of the host hosting the data are collected. Specifically, during resource metric collection, the following system resource metrics of the host hosting the database need to be collected within the slow SQL execution time window: CPU utilization (overall and database process percentages); disk I / O throughput (read / write IOPS, await latency); memory utilization and swap usage; and database shared buffer hit rate (shared_blks_hit / (shared_blks_hit+shared_blks_read)).

[0036] Furthermore, based on the regularly persisted snapshots of the execution plans generated by high-frequency SQL, it is also necessary to compare the database SQL version triggered by slow SQL with the historical database SQL version, identify the root causes of plan mutations, and collect and determine the historical comparison characteristics of the execution plan.

[0037] In one embodiment, during the collection of historical comparison features of execution plans, the system periodically persists execution plan snapshots for high-frequency SQL queries. When a slow SQL query is triggered, the snapshots are compared with historical versions to identify the root cause of plan mutations. The collection of this dimension feature (historical comparison features of execution plans) also needs to include an SQL fingerprint generation mechanism and an execution plan snapshot storage structure and hash calculation mechanism. In other words, execution plan features, statistical information features, lock wait features, resource indicator features, and historical comparison features of execution plans together constitute multidimensional feature data.

[0038] Furthermore, before collecting and determining the historical comparison features of the execution plan, the SQL texts with the same logic but different versions are normalized, and the normalized SQL texts are then replaced with parameter placeholders under relevant regular expressions to obtain the replaced SQL texts.

[0039] Furthermore, based on the replaced SQL text, the corresponding hash value is calculated, and a unique fingerprint identifier is generated for the replaced SQL text. Using this unique fingerprint identifier as the primary key, the execution plan snapshot, historical performance data, and root cause diagnostic records of the current SQL are associated with it.

[0040] In one embodiment, to compare the execution plans of SQL statements with the same logic across time, the system needs to generate a stable fingerprint for the SQL text, so that SQL statements with different parameters but the same logic can be identified as the same SQL statement. The steps for generating a unique fingerprint are as follows: Step 1: SQL text normalization: Convert the SQL text to lowercase; remove leading and trailing whitespace characters, and replace consecutive whitespace characters with single spaces; remove comment content (single-line comments and block comments). Step 2: Parameter placeholder replacement: For the normalized SQL text, use regular expressions to identify and replace the following types of literals: numeric literals (integers, floating-point numbers) → replace; string literals (content enclosed in single quotes) → replace; multiple parameters in the IN list IN(1,2,3) → replace with IN(?); numbers after LIMIT / OFFSET → replace. For example: Original SQL: SELECT FROM orders WHERE user_id=12345 AND status='paid' LIMIT 10; fingerprint SQL: select Step 3: Generate fingerprint hash: Calculate the MD5 hash value for the replaced fingerprint SQL text, which serves as the unique fingerprint identifier (sql_fingerprint) for that SQL. The system uses sql_fingerprint as the primary key, linking it to the SQL's execution plan snapshot, historical performance data, and root cause diagnostic records.

[0041] In one embodiment, the high-frequency SQL determination rule is as follows: The system maintains an execution counter with a unique fingerprint identifier sql_fingerprint as the key, which counts the number of executions within a sliding time window (default 5 minutes). When the number of executions exceeds a preset threshold (default 10 times / 5 minutes, configurable), the SQL is marked as high-frequency SQL and included in the execution plan snapshot collection scope.

[0042] Furthermore, based on the structural changes in the execution plan, it is necessary to calculate the hash value of the relevant strings for the structural fields of each node in the execution structure to obtain the execution plan structure hash. Then, based on the execution plan structure hash and the unique fingerprint identifier, an execution plan snapshot table is constructed. The execution plan snapshot table also includes: an auto-incrementing primary key, a database instance identifier, the complete execution plan JSON text, an execution plan summary, the snapshot collection time, the average execution time, and the number of sampled SQL executions corresponding to the execution plan snapshot.

[0043] Furthermore, when slow SQL data status is detected in the database, the current execution plan snapshot table must be compared and diagnosed with the historical execution plan snapshot table to identify the root causes of plan mutations, and the historical comparison features of the execution plan must be output.

[0044] In one embodiment, a snapshot storage table structure needs to be constructed. The system maintains an execution plan snapshot table (plan_snapshot) in the operation and maintenance management database. The table structure is defined as shown in Table 1: Table 1 Maintenance Execution Plan Snapshot Table

[0045] The system retains snapshots of the most recent N versions for each (sql_fingerprint, db_instance_id) combination (default N=10, configurable). When the number of versions is exceeded, the oldest record is deleted.

[0046] In one implementation, the method for calculating the execution plan structure hash (plan_hash) in the execution plan snapshot table includes: The goal of plan_hash calculation is to capture only structural changes in the execution plan, ignoring dynamic values ​​(such as actual rows and actual time) for each execution, thereby accurately determining whether the plan has undergone a fundamental change. The calculation steps are as follows: 1) Parse the execution plan JSON and recursively traverse all plan nodes; 2) For each node, extract the following structure fields: Node Type (node ​​type, such as Seq Scan, IndexScan); Relation Name (table name involved, if it exists); Index Name (index name used, if it exists); JoinType (join type, if it exists); Sort Key (list of sort keys, if it exists). 3) Ignore the following dynamic fields: runtime data such as Actual Rows, Actual Time, and Rows Removed by Filter; 4) Serialize all node structure fields into strings in depth-first order; 5) Calculate the MD5 hash of the string to obtain the plan_hash.

[0047] In one embodiment, the timing of snapshot collection includes: actively collecting a snapshot of high-frequency SQL every fixed period (default hour); immediately collecting a snapshot of the current execution plan when a slow SQL alarm is triggered; and forcibly refreshing the snapshot of all high-frequency SQL when the system restarts or database parameter changes.

[0048] In one embodiment, the planned mutation detection logic includes: when a slow SQL query triggers a diagnostic, the system executes the following comparison process: 1) Obtain the unique fingerprint of the current SQL statement: sql_fingerprint; 2) Query the plan_snapshot table and retrieve the most recent historical snapshot of this fingerprint within the same instance; 3) Calculate the plan_hash of the current execution plan and compare it with the plan_hash of the historical snapshot: if the plan_hash is the same → the plan has not changed, feature item f8=false; if the plan_hash is different → the plan has changed, f8=true, further extract the node differences in plan_summary and fill in feature item f9; 4) Record the change time point (the difference between captured_at of the two snapshots) as an evidence field for use in the diagnostic report output.

[0049] Furthermore, after slow SQL is triggered for detection, the concurrent acquisition coordinator performs concurrent acquisition processing on the multi-dimensional feature data based on the timeout limit difference for each dimension feature.

[0050] As a possible implementation method, such as Figure 2As shown, the five-dimensional feature (multi-dimensional feature data) collection tasks are executed concurrently after the slow SQL is triggered, and are uniformly managed by the concurrent collection coordinator. The concurrent coordination process is as follows: 1) Slow SQL is triggered; 2) The coordinator creates a collection context (CollectContext) including: sql_fingerprint, db_instance_id, trigger timestamp, and timeout configuration; 3) Five collection tasks (asynchronous threads / coroutines) are dispatched concurrently, including: Task-1: Execution plan collection (timeout limit: T1=5 seconds), Task-2: Statistics information collection (timeout limit: T2=3 seconds), Task-3: Lock wait collection (timeout limit: T3=2 seconds), Task-4: Resource level collection (timeout limit: T4=3 seconds), and Task-5: Plan history comparison (timeout limit: T5=2 seconds); 4) Wait for all tasks to complete (total timeout limit: Tmax=8 seconds); 5) Collect the results of each task and mark the completion status (COMPLETED / TIMEOUT / ... ERROR); 6) Enter the feature vector construction and normalization module for processing.

[0051] The reasons for the differentiated timeout limits for each collection task are as follows: Execution plan collection (T1=5 seconds): EXPLAIN ANALYZE requires actual SQL execution, which takes a long time, so a more lenient timeout is given; Lock wait collection (T3=2 seconds) and plan history comparison (T5=2 seconds): Only queries the memory view or local snapshot table, so the response should be extremely fast, and a timeout is considered abnormal.

[0052] As a feasible implementation method, the execution plan acquisition also needs to be designed with low intrusion. That is, EXPLAIN ANALYZE will actually execute the SQL, and write operations (INSERT / UPDATE / DELETE) in a production environment may cause data pollution. The system adopts the following strategies to avoid risks: 1) For SELECT-type SQL, directly execute EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON); 2) For write operation-type SQL (DML), use EXPLAIN (FORMAT JSON) (without ANALYZE), only obtain the estimated execution plan, and do not actually execute it. The feature item f2 (row number estimation deviation rate) field is marked as "unavailable" in this case; 3) The acquisition operation is executed in a separate database connection, and the statement_timeout is set to T1 to prevent the acquisition operation itself from becoming a new slow SQL; 4) The collection connection uses a read-only account to prevent accidental operation from affecting business data.

[0053] Furthermore, the missing dimensional features in the multidimensional feature data are detected, and the missing feature terms corresponding to the missing dimensional features are marked. Then, based on different missing dimensional features and their corresponding missing feature terms, a missing feature handling strategy is executed to obtain the missing dimensional features. The missing feature handling strategy is a decision tree execution strategy for each type of missing dimensional feature.

[0054] Furthermore, if there are more than three missing dimension features, the multidimensional feature data acquisition strategy will be switched to a manual acquisition strategy, and the reason for the failure to acquire the missing dimension features will be output.

[0055] In one embodiment, missing features also need to be handled. When a dimension's data collection times out or an error occurs, the corresponding feature item is marked as missing (NULL). The system handles missing features during the feature vector construction stage and the decision tree judgment stage, as shown in Table 2: Table 2 Missing Dimension Handling Strategies

[0056] When more than three dimensions of data are missing, the system considers the diagnostic data insufficient and does not output the root cause conclusion. Instead, it outputs a prompt that "data collection is incomplete, manual investigation is recommended," switches the collection strategy for multidimensional feature data to the manual collection strategy, and lists the reasons for the failure of collection for each dimension.

[0057] S102. The multidimensional feature data in the completed acquisition state is subjected to feature vector construction and normalization to obtain multidimensional structural feature vectors.

[0058] Specifically, using preset feature extraction rules, each feature item in the multidimensional feature data is extracted, and the extracted feature items are transformed into structured features to obtain a multidimensional structured feature vector. Each feature item includes: feature number, feature name, value type, and description.

[0059] In one embodiment, such as Figure 2 As shown, the raw data collected from the above five dimensions are transformed into a multi-dimensional structural feature vector F=[f1,f2,...,f...] according to predefined feature extraction rules. n The definitions of each feature are as follows (partial examples), as shown in Table 3: Table 3 Feature Item Definition Table

[0060] S103. Perform root cause classification processing on the multidimensional structural feature vectors using a root cause classification decision tree, and output a list of root cause types sorted by confidence level based on the confidence level of multiple root causes.

[0061] Specifically, using a root cause classification decision tree, the multi-dimensional structural feature vector is subjected to threshold judgment of combined feature terms based on the root cause generation conditions to obtain the root cause type and the root cause confidence level corresponding to each root cause type. Here, the combined feature terms are all the associated feature terms included in the root cause generation conditions.

[0062] In one embodiment, such as Figure 2 As shown, root cause classification is performed using a multi-level decision tree based on multi-dimensional structural feature vectors. Based on Table 3, the decision tree process is as follows: Input multidimensional structural feature vector F: If [f4=true AND f5>0.3], then the root cause is lock contention, confidence = f5×100%; if [f8=true AND (f1 significantly increases OR f2 significantly changes)], then the root cause is plan regression, confidence = plan_node_diff_score×100%; if [f1>0.5 AND f3<0.4 AND f2>5], then the root cause is stalestatistics, confidence = (1-f3)×min(f2 / 10,1)×100%; if [f1>0.5 AND f3≥0.4 AND f2≤5], then the root cause is missing or invalid index, confidence = f1×100%; if [f5>0.85 AND f...], then the root cause is lock contention, confidence = f5×100%; if [f5>0.85 AND f...], then the root cause is lock contention, confidence = f5×100%; if [f5>0.85 AND f5 ... 10 If <0.7 AND f7>20], then the root cause is I / O resource contention (I / O Bottleneck), with confidence level = f5 × 0.4 + (1 - f 10 )×0.3+min(f7 / 100,1)×0.3; if [f6>0.85 AND f 10 If the confidence level is ≥0.7, then the root cause is CPU resource contention (CPU Bottleneck), with a confidence level of f6 × 0.7 + f 10 ×0.3.

[0063] The calculation method for the execution plan mutation confidence score (plan_node_diff_score) requires comparing the node lists in the plan_summary of the old and new execution plans and calculating the node difference score: 1) Count the number of nodes that have undergone type changes (e.g., Index Scan → Seq Scan counts as 1 change); 2) Count the total number of nodes in the plan (total_nodes); 3) Assign extra weight to key node type changes: the weight coefficient for Seq Scan replacing Index Scan is 2.0, and the weight coefficient for other node changes is 1.0; 4) Calculation formula: plan_node_diff_score = min(Σ(change node weight) / total_nodes, 1.0).

[0064] Furthermore, when the root cause classification decision tree identifies multiple root cause branches and triggers them simultaneously, the root cause confidence level corresponding to each root cause type after triggering is normalized.

[0065] Furthermore, all the normalized root cause confidence scores are sorted in descending order to generate a root cause type list sorted by confidence score. This root cause type list contains multiple candidate root causes, with the top-ranked root cause type being the primary root cause.

[0066] In one embodiment, such as Figure 2 As shown, when the root cause classification decision tree determines that multiple root cause branches are triggered simultaneously, the confidence scores of each root cause are subjected to Softmax normalization to ensure that the sum of the confidence scores of all candidate root causes is 1. This facilitates the understanding of the relative probability of each root cause by operations and maintenance personnel. The normalization formula is: P(rootcause_i) = exp(score_i) / Σexp(score_j). After normalization, the root cause list is output in descending order of P value, with the highest P value displayed as the primary root cause. When multiple branch conditions are met simultaneously, the system outputs multiple candidate root causes, arranged in descending order of confidence score, with the highest confidence score selected as the primary root cause.

[0067] S104. Perform root cause treatment template matching processing on each root cause type in the root cause type list, and obtain a search strategy based on the scope of influence of the root cause type based on the other SQL lists affected by the same root cause type.

[0068] Specifically, the process also requires recommending treatment measures for each root cause type in the root cause type list using the root cause treatment template, resulting in treatment suggestions. Root cause labels are then generated based on the root cause type and its corresponding confidence level. Finally, key evidence is generated based on the feature values ​​that trigger root cause judgments and the comparison values ​​of abnormal thresholds in the root cause classification decision tree.

[0069] In one embodiment, such as Figure 2 As shown in Table 4, the correspondence between root cause types and treatment recommendations is as follows: Table 4. Root Cause Types and Treatment Recommendations

[0070] Furthermore, based on the diffusion dimensions of different root cause types, other SQL queries sharing the same root cause type as the current slow SQL are queried and processed to determine a list of other SQL queries affected by the same root cause type, and a search strategy based on the scope of influence of the root cause type is generated. The shared root cause types include: lock wait, execution plan mutation, statistical information bias, missing or invalid indexes, and resource contention.

[0071] In one implementation, in the root cause type impact scope identification, the impact scope refers to other SQL queries that share the same root cause as the current slow SQL query, helping operations personnel identify potential systemic issues behind a single alarm. In the root cause type impact scope lookup strategy, different root cause types have different impact scope propagation paths. The system employs a corresponding lookup strategy for each root cause, as shown in Table 5: Table 5. Root Cause Types and Finding Methods

[0072] S105. Generate a slow SQL root cause diagnosis report based on the treatment suggestions obtained by matching the search strategy with the root cause treatment template.

[0073] Specifically, based on the unique fingerprint identifier of other SQL lists affected by the same root cause type, the information of the corresponding related SQL template text, the average execution time and number of calls of the related SQL in the current time window, and the judgment criteria for sharing the root cause with the current slow SQL are aggregated to obtain the scope of influence results.

[0074] In one embodiment, the impact range results of the root cause type also need to be aggregated. The list of associated SQL fingerprints (unique fingerprint identifiers) is aggregated and output to the diagnostic report based on the following information: 1) The SQL template text corresponding to the SQL fingerprint (the fingerprint SQL after de-identification parameters); 2) The average execution time and number of calls of the SQL in the current time window; 3) The basis for judging whether it shares a root cause with the current slow SQL (association evidence). The final output will display a maximum of the top 10 associated SQLs, sorted in descending order of the number of calls, prioritizing the display of high-frequency and high-impact associated SQLs.

[0075] Furthermore, such as Figure 2As shown, based on the impact scope results, search strategy, key evidence, root cause labels, and handling suggestions, a slow SQL root cause diagnostic report is finally generated. That is, the system needs to automatically generate a diagnostic report for each root cause type, containing the following: Root cause label: root cause type name and confidence percentage; Key evidence: feature values ​​that triggered the root cause judgment and anomaly threshold comparison; Handling suggestions: recommended action steps for the root cause; Impact scope: a list of other SQL queries affected by the same root cause; Search strategy: different root cause types have different impact scope diffusion paths, and the system adopts a corresponding search strategy for each root cause.

[0076] In addition, embodiments of this application also provide a device for automatically locating the root causes of slow SQL queries in a database, such as... Figure 3 As shown, the database slow SQL root cause automatic location device 300 specifically includes: At least one processor 301; and a memory 302 communicatively connected to the at least one processor 301; wherein the memory 302 stores instructions executable by the at least one processor 301 to enable the at least one processor 301 to execute: When slow SQL data status is detected in the database, multi-dimensional feature data of the target SQL is collected. The multi-dimensional feature data includes: execution plan features, statistical information features, lock wait features, resource indicator features, and historical comparison features of execution plans. The multidimensional feature data that has been collected is processed to construct and normalize feature vectors to obtain multidimensional structural feature vectors. Perform root cause classification processing on the multidimensional structural feature vectors using a root cause classification decision tree, and output a list of root cause types sorted by confidence level based on the confidence level of multiple root causes. Each root cause type in the root cause type list is matched with a root cause treatment template, and a search strategy based on the scope of influence of the root cause type is obtained based on the list of other SQL statements affected by the same root cause type. Based on the handling suggestions matched with the search strategy and the root cause handling template, a slow SQL root cause diagnostic report is generated.

[0077] This application's embodiments, through multi-dimensional feature data, overcome the limitations of traditional single-dimensional diagnostics. They can capture slow SQL problems caused by multiple factors such as execution plan mutations, outdated statistics, lock contention, resource bottlenecks, or plan regression, effectively avoiding missed diagnoses and misdiagnoses from a single perspective, making root cause localization more complete and reliable. Furthermore, based on the introduced historical execution plan comparison features, it endows root cause diagnosis with dynamic time-dimensional perception capabilities, accurately identifying plan degradation problems caused by optimizer decision bias, bind variable snooping, and delayed statistical information updates. It also employs a decision tree model to classify the multi-dimensional structured feature vectors into root causes and outputs a list of root cause types sorted in descending order of confidence. This provides a quantitative ranking of confidence levels when multiple potential causes exist, assisting operations personnel in prioritizing the most likely causes while not overlooking suboptimal candidates, effectively balancing diagnostic accuracy and recall. It can also provide information on the specific repair actions for slow SQL queries and predict in advance other business SQL queries that may be affected by the root cause, thereby supporting batch processing, impact assessment, and pre-change risk assessment, significantly reducing the workload of repetitive diagnosis and lowering the probability of secondary problems caused by local repairs.

[0078] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0079] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0080] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0081] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0082] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0083] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0084] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0085] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0086] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0087] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0088] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of this specification.

Claims

1. A method for automatically locating the root cause of slow SQL queries in a database, characterized in that, The method includes: When a slow SQL data state is detected in the database, multi-dimensional feature data of the target SQL is collected; wherein, the multi-dimensional feature data includes: execution plan features, statistical information features, lock wait features, resource indicator features, and historical comparison features of execution plans; Specifically, based on the execution plan snapshots periodically persisted by high-frequency SQL queries, the database SQL version triggered by slow SQL queries is compared with the historical database SQL version. The root causes of plan mutations are identified, and the historical comparison characteristics of the execution plan are collected and determined, including: Before collecting and determining the historical comparison features of the execution plan, the SQL texts with the same logic but different versions are normalized, and the normalized SQL texts are replaced with parameter placeholders under relevant regular expressions to obtain the replaced SQL texts. Based on the replaced SQL text, calculate the corresponding hash value and generate a unique fingerprint identifier for the replaced SQL text; use the unique fingerprint identifier as the primary key to associate the current SQL execution plan snapshot, historical performance data, and root cause diagnosis records; Based on the structural changes in the execution plan, hash values ​​of relevant strings are calculated for the structural fields of each node in the execution plan to obtain the execution plan structure hash; and based on the execution plan structure hash and the unique fingerprint identifier, an execution plan snapshot table is constructed; wherein, the execution plan snapshot table also includes: an auto-incrementing primary key, a database instance identifier, the complete execution plan JSON original text, an execution plan summary, a snapshot collection time, an average execution time, and the number of sampled SQL executions corresponding to the execution plan snapshot; When slow SQL data status is detected in the database using the execution plan snapshot table, the current execution plan snapshot table of the current execution plan snapshot is compared and diagnosed with the historical execution plan snapshot table of the historical execution plan snapshot, and the historical comparison features of the execution plan are output. The multidimensional feature data in the completed acquisition state are subjected to feature vector construction and normalization to obtain multidimensional structure feature vectors. The multidimensional structural feature vector is subjected to root cause classification processing using a root cause classification decision tree, and a list of root cause types sorted by confidence level is output based on the confidence level of multiple root causes. Each root cause type in the root cause type list is matched with a root cause treatment template, and a search strategy based on the scope of influence of the root cause type is obtained based on the list of other SQL statements affected by the same root cause type. Based on the search strategy and the treatment suggestions matched with the root cause treatment template, a slow SQL root cause diagnosis report is generated.

2. The method for automatically locating the root cause of slow SQL queries in a database according to claim 1, characterized in that, When a slow SQL query is detected in the database, multi-dimensional feature data of the target SQL query is collected, specifically including: When a slow SQL data status is detected in the database, the key features of the execution plan are extracted from the target SQL to obtain the execution plan features. The key features of the execution plan include: the type of scanning node, the deviation rate of the estimated number of rows of each node, the proportion of the actual time spent by each node to the total execution time, sorting overflow, and hash join memory overflow. Based on the tables and columns involved in the target SQL, the database system view is queried to extract and obtain the statistical information features; wherein, the statistical information features include: statistical information freshness, data change volume, deviation between the number of duplicate values ​​and the actual value of high-frequency columns, and abnormal proportion of null values; The lock wait characteristics are collected and obtained by querying the database wait events and lock views; wherein, the lock wait characteristics include: the lock wait state of the target SQL during execution, the duration and lock type of the lock wait, the source and duration of the lock-holding transaction, and the depth of the lock wait chain; Within the slow SQL execution time window, the resource metrics characteristics of the host where the data is located are collected.

3. The method for automatically locating the root cause of slow SQL queries in a database according to claim 1, characterized in that, When a slow SQL query is detected in the database, multidimensional feature data of the target SQL query is collected, including: After slow SQL is triggered, the multidimensional feature data is processed by the concurrent acquisition coordinator based on the timeout limit difference of each dimension feature through concurrent acquisition. The missing dimension features in the multidimensional feature data are detected and processed, and the missing feature items corresponding to the missing dimension features are marked. Based on different missing dimension features and the corresponding missing feature items, a missing-time processing strategy is executed to obtain the missing dimension features; wherein, the missing-time processing strategy is a decision tree execution strategy for each missing dimension feature. If there are three or more missing dimension features, the acquisition strategy for the multidimensional feature data will be switched to a manual acquisition strategy, and the acquisition failure information for the missing dimension features will be output.

4. The method for automatically locating the root cause of slow SQL queries in a database according to claim 1, characterized in that, The multidimensional feature data in the completed acquisition state is subjected to feature vector construction and normalization to obtain multidimensional structural feature vectors, specifically including: According to the preset feature extraction rules, each feature item in the multidimensional feature data is extracted, and the extracted feature items are transformed into structured features to obtain the multidimensional structured feature vector; wherein, each feature item includes: feature number, feature name, value type and description.

5. The method for automatically locating the root cause of slow SQL queries in a database according to claim 1, characterized in that, The multidimensional structural feature vector is subjected to root cause classification processing using a root cause classification decision tree, and based on the confidence of multiple root causes, a list of root cause types sorted by confidence is output, specifically including: By using a root cause classification decision tree, the multidimensional structural feature vector is subjected to a threshold judgment of combined feature terms based on the root cause generation conditions to obtain the root cause type and the root cause confidence level corresponding to each root cause type; wherein, the combined feature terms are all the associated feature terms included in the root cause generation conditions. When the root cause classification decision tree identifies multiple root cause branches and triggers them simultaneously, the root cause confidence level corresponding to each root cause type after triggering is normalized. All normalized root cause confidence scores are sorted in descending order to generate a root cause type list sorted by confidence score; wherein, the root cause type list contains multiple candidate root causes, and the root cause type at the top of the root cause type list is the main root cause.

6. The method for automatically locating the root cause of slow SQL queries in a database according to claim 1, characterized in that, Each root cause type in the root cause type list is matched against a root cause treatment template, and a search strategy based on the scope of influence of the root cause type is obtained based on the list of other SQL statements affected by the same root cause type. Specifically, this includes: Using the root cause treatment template, treatment measures are recommended for each root cause type in the root cause type list to obtain treatment suggestions; and root cause labels are generated based on the root cause type and the corresponding root cause confidence; and key evidence is generated based on the feature values ​​that trigger root cause judgment and the anomaly threshold comparison values ​​in the root cause classification decision tree. Based on the diffusion dimensions of different root cause types, query processing is performed on other SQL queries that share the same root cause type as the current slow SQL query to determine the list of other SQL queries affected by the same root cause type, and the search strategy based on the scope of influence of the root cause type is generated; wherein, the shared same root cause type includes: lock wait, execution plan mutation, statistical information deviation, missing or invalid index, and resource contention.

7. The method for automatically locating the root cause of slow SQL queries in a database according to claim 6, characterized in that, Based on the matching suggestions obtained from the search strategy and the root cause treatment template, a slow SQL root cause diagnosis report is generated, specifically including: Based on the unique fingerprint identifier of other SQL lists affected by the same root cause type, the information of the corresponding related SQL template text, the average execution time and number of calls of the related SQL in the current time window, and the judgment criteria for sharing the root cause with the current slow SQL are aggregated to obtain the impact range result; Based on the impact range results, the search strategy, the key evidence, the root cause labels, and the treatment recommendations, the slow SQL root cause diagnostic report is generated.

8. A device for automatically locating the root cause of slow SQL queries in a database, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor to enable the at least one processor to execute a method for automatically locating the root cause of slow SQL queries in a database, according to any one of claims 1-7.

9. A non-volatile computer storage medium, characterized in that, The storage medium is a non-volatile computer-readable storage medium that stores at least one program, each program including instructions that, when executed by a terminal, cause the terminal to perform an automatic database slow SQL root cause localization method according to any one of claims 1-7.

Images