Method and apparatus for visualizing query interpretation analysis results

Abstract

This application provides a method and apparatus for visualizing query interpretation analysis results. The method includes: obtaining the text-based interpretation analysis results corresponding to a target query statement; determining, from the interpretation analysis results, multiple query nodes constituting the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and various query metrics corresponding to each of the multiple query nodes. Based on the dependencies between the multiple query nodes, displaying a tree diagram corresponding to the query plan on the target interface, and binding the multiple query metrics corresponding to each of the multiple query nodes to the tree diagram, thereby realizing the visual display of the query plan and the binding display of query nodes and query metrics in the visualization results.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and device for visualizing query interpretation and analysis results. Background Technology

[0002] The `EXPLAIN ANALYZE` command is a PostgreSQL command used in daily work to understand and optimize the query process of SQL statements. It can be used to analyze the query plan and query metrics of a query statement. The query plan includes multiple query nodes with call relationships (or dependencies), each representing a specific query operation. Each query node can be associated with corresponding query metrics, such as time-related metrics, memory usage, and parallelism.

[0003] By using the `EXPLAIN ANALYZE` command, users can better understand the execution process and performance of queries, enabling targeted performance optimization. The output of the `EXPLAIN ANALYZE` command is in text format. In the context of big data, with the massive increase in data volume, text-based query analysis results become difficult for ordinary users to understand. To facilitate user understanding of the query analysis results, they can be visualized. Summary of the Invention

[0004] This invention provides a method and device for visualizing query interpretation and analysis results, which enables the visualization of the interpretation and analysis results of query statements and allows for the binding of query plans and query indicators within the visualized results.

[0005] In a first aspect, embodiments of the present invention provide a method for visualizing query interpretation analysis results, the method comprising:

[0006] Obtain the text-based interpretation and analysis results corresponding to the target query statement;

[0007] From the interpretation and analysis results, we determine multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and the various query indicators corresponding to each of the multiple query nodes.

[0008] Based on the dependencies between the multiple query nodes, a tree diagram corresponding to the query plan is displayed on the target interface, and various query metrics corresponding to each of the multiple query nodes are bound to the tree diagram.

[0009] Secondly, embodiments of the present invention provide a visualization processing device for query interpretation analysis results, the device comprising:

[0010] The acquisition module is used to obtain the text-based interpretation and analysis results corresponding to the target query statement;

[0011] The determination module is used to determine, from the interpretation and analysis results, multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and various query indicators corresponding to each of the multiple query nodes;

[0012] The display module is used to display a tree diagram corresponding to the query plan in the target interface according to the dependency relationship between the multiple query nodes, and to bind various query indicators corresponding to each of the multiple query nodes in the tree diagram.

[0013] Thirdly, embodiments of the present invention provide an electronic device, including: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, it performs the visualization processing method for query interpretation analysis results as described in the first aspect.

[0014] Fourthly, embodiments of the present invention provide a non-transitory machine-readable storage medium storing executable code. When the executable code is executed by a processor in an electronic device, at least the visualization processing method for query interpretation and analysis results as described in the first aspect can be implemented.

[0015] The solution provided in this embodiment of the invention can be applied to real-time data warehouse engines integrated with PostgreSQL. When an `Explain analyze` command is executed on a target query statement, the analysis results in text format (e.g., JSON, TXT) are obtained. Based on predefined query metrics to be analyzed, multiple query nodes constituting the query plan for the target query statement, the dependencies between these nodes, and the various query metrics corresponding to each node can be determined from the analysis results. Finally, based on the dependencies between the multiple query nodes, a tree diagram of the query plan is displayed on the target interface. The tree diagram is then bound to the various query metrics corresponding to each query node, thereby achieving a visual display of the query plan and a binding display of query nodes and query metrics in the visualization results. This allows users to clearly and conveniently see the execution status of each query node. Attached Figure Description

[0016] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram illustrating the execution process of a visualization processing method for query interpretation analysis results provided in an embodiment of the present invention;

[0018] Figure 2 A flowchart illustrating a method for visualizing query interpretation and analysis results provided in an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram of a query plan in a JSON format query interpretation and analysis result provided in an embodiment of the present invention;

[0020] Figure 4 This is a schematic diagram of query indicators in a JSON format query interpretation and analysis result provided in an embodiment of the present invention;

[0021] Figure 5 This is a schematic diagram illustrating a visualization of query interpretation and analysis results provided in an embodiment of the present invention;

[0022] Figure 6 This is a schematic diagram illustrating a visualization of query interpretation and analysis results provided in an embodiment of the present invention;

[0023] Figure 7 A flowchart illustrating a method for visualizing query interpretation and analysis results provided in an embodiment of the present invention;

[0024] Figure 8 This is a schematic diagram illustrating a visualization of query interpretation and analysis results provided in an embodiment of the present invention;

[0025] Figure 9 A flowchart illustrating a method for visualizing query interpretation and analysis results provided in an embodiment of the present invention;

[0026] Figure 10 This is a schematic diagram illustrating a visualization of query interpretation and analysis results provided in an embodiment of the present invention;

[0027] Figure 11 A flowchart illustrating a method for visualizing query interpretation and analysis results provided in an embodiment of the present invention;

[0028] Figure 12 This is a schematic diagram illustrating a visualization of query interpretation and analysis results provided in an embodiment of the present invention;

[0029] Figure 13 This is a schematic diagram of the structure of a visualization processing device for query interpretation and analysis results provided in an embodiment of the present invention;

[0030] Figure 14 This is a schematic diagram of the structure of an electronic device provided in this embodiment. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. In addition, the timing of the steps in the following method embodiments is only an example and not a strict limitation.

[0032] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in the embodiments of the present invention are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0033] First, some concepts involved in the embodiments of this invention will be explained.

[0034] A real-time data warehouse engine is a real-time massive data processing engine that supports real-time writing, updating, processing, and analysis of massive amounts of data. It supports standard SQL and is compatible with PostgreSQL. It adopts an architecture that separates computation and storage. Data is stored in an underlying distributed file storage system, while computation is provided by an upper-layer elastically scalable server cluster.

[0035] Query observability refers to the ability to monitor and observe the execution process of a query. To observe resource consumption and time consumption at each stage of query execution, the real-time data warehouse engine defines a series of query metrics to achieve query observability. These defined metrics help users understand the execution status of queries, monitor query performance and resource usage, locate query problems and anomalies, and thus adjust and optimize query strategies in a timely manner.

[0036] The `Explain analyze` command provides detailed information about the execution of a query statement, including query metrics such as query plan, execution time, disk I / O, and CPU usage. Based on query metrics defined in the real-time data warehouse engine according to actual application scenarios, using the `Explain analyze` command on a given query statement yields various query metrics corresponding to that query statement. The `Explain analyze` command in this embodiment includes, but is not limited to, the `Explainanalyze` command in the real-time data warehouse engine scenario.

[0037] A query plan is the execution plan for a query statement, describing the process of executing the query in the database. It can be visualized using a tree diagram. Each node in the tree is a query node, representing a specific operation that needs to be performed during the execution process. The query plan is executed from bottom to top, with the root node ultimately returning the query results.

[0038] As mentioned earlier, executing the `Explain analyze` command on a query statement yields explanatory analysis results in text format, such as JSON or TXT. These text-based results include a textual description of the query plan and metrics, which can be difficult to understand, especially in the context of big data. The query plan in these results often involves numerous query nodes, resulting in lengthy textual descriptions that hinder intuitive understanding of the query process. Therefore, visualizing the textual explanatory analysis results—displaying the query plan and metrics graphically—would significantly improve the user experience.

[0039] Taking a real-time data warehouse engine scenario as an example, a visualization tool is deployed within the engine. This tool takes the text-based explanatory analysis results output by the `Explain analyze` command as input and generates visual representations. This visualization tool is compatible with various query metrics defined in the real-time data warehouse scenario and supports dynamic updates (such as adding or deleting) of these metrics. It can bind query nodes to query metrics and handle bottlenecks and skew warnings during the visualization process, allowing users to intuitively understand performance bottlenecks in query execution and their causes, thus facilitating query plan optimization.

[0040] First, combine Figure 1 This section provides a macroscopic illustration of the execution process of the visualization method for interpreting and analyzing query results. Figure 1 The assumptions made here are based on application scenarios in real-time data warehouse engines, such as... Figure 1As shown in the diagram, a user submits an Explainanalyze command to the real-time data warehouse engine for a specific target query, and receives the explanation and analysis results in text format (such as TXT or JSON format as illustrated in the diagram). Figure 1 The visualization tool for the explanatory analysis results shown in the diagram takes the explanatory analysis results in text form as input. Through processing steps such as multi-granularity parsing of query indicators, indicator binding, bottleneck identification, skew warning, and statistical error correction, it displays the visualization results of the explanatory analysis results output by the Explain analyze command, thereby helping users quickly understand the query plan, locate query bottlenecks, and troubleshoot query problems.

[0041] The following examples illustrate the process of visualizing the interpretation and analysis results of query statements.

[0042] Figure 2 This is a flowchart illustrating a method for visualizing query interpretation and analysis results according to an embodiment of the present invention. This method can be executed by a visualization tool, which can be deployed in a real-time data warehouse engine, such as... Figure 2 As shown, the method may include the following steps:

[0043] 201. Obtain the text-based interpretation and analysis results corresponding to the target query statement.

[0044] 202. From the interpretation and analysis results, determine the multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and the various query indicators corresponding to each of the multiple query nodes.

[0045] 203. Based on the dependencies between multiple query nodes, display a tree diagram of the query plan on the target interface, and bind various query metrics to the multiple query nodes in the tree diagram.

[0046] Taking a real-time data warehouse engine as an example, it supports standard SQL and is compatible with PostgreSQL. This allows you to submit the corresponding Explain analyze command for a target query statement (SQL statement). Furthermore, depending on the current real-time data warehouse engine scenario, you can predefine query metrics of different dimensions. During the execution of the Explain analyze command, the corresponding query metrics are calculated, and finally, you get the interpretation and analysis results in text form (such as TXT or JSON format). The interpretation and analysis results include the query plan and query metrics corresponding to the target query statement, but the query plan and query metrics are described in text form.

[0047] In practical applications, when an exception occurs during the execution of a target query statement—typically a query failure or an execution time exceeding the expected time—users can trigger the `Explain analyze` command to understand the specific execution status of the target query statement. Alternatively, users can trigger the `Explain analyze` command to understand the specific execution status of the target query statement.

[0048] Specifically, users can submit the `Explainanalyze` command in the real-time data warehouse engine, such as "Explainanalyze select xxx", where `select xxx` represents the target query statement. The real-time data warehouse engine will then execute this command and output an explanatory analysis result consisting of a text-based query plan and query metrics to help users understand the query plan and observe the reasons for query execution anomalies.

[0049] Executing the `Explainanalyze` command above will output the explanation and analysis results in TXT text format. For ease of understanding, the following example illustrates the explanation and analysis results in TXT text format corresponding to the target query statement in this embodiment of the invention:

[0050] 1. Query Plan

[0051] Sort(cost=0.00..7795.30 rows=3 width=80)

[0052] SortKey:l_returnflag,l_linestatus

[0053] [id=21dop=1time=2427 / 2427 / 2427msrows=4(4 / 4 / 4)mem=3 / 3 / 3KBopen=2427 / 2427 / 2427ms get_next=0 / 0 / 0ms]

[0054] ->Gather(cost=0.00..7795.27rows=3width=80)

[0055] [20:1 id=100003 dop=1 time=2426 / 2426 / 2426ms rows=4(4 / 4 / 4)mem=1 / 1 / 1KB open=0 / 0 / 0msget_next=2426 / 2426 / 2426ms]

[0056] ->Project(cost=0.00..7795.27rows=3width=80)

[0057] [id=19 dop=20 time=2427 / 2426 / 2425ms rows=4(1 / 0 / 0)mem=87 / 87 / 87KBopen=2427 / 2425 / 2425ms get_next=1 / 0 / 0ms]……

[0058] 2. Time consumed in each execution stage

[0059] TOTALcost:

[2505] ms

[0060] Optimizer cost:

[47] ms

[0061] Initgangscost:[4]ms

[0062] Buildgangdesctablecost:[2]ms

[0063] Startquerycost:

[18] ms

[0064] Get the first block cost:

[2434] ms

[0065] Getresultcost:

[2434] ms

[0066] ...

[0067] 3. Resource occupancy status

[0068] Memory: 921 (244 / 230 / 217) MB

[0069] CPUtime:149772(38159 / 37443 / 36736)ms

[0070] Physicalreadbytes:3345(839 / 836 / 834)MB

[0071] Readbytes:41787(10451 / 10446 / 10444)MB

[0072] ...

[0073] As shown in the example above, the explanation and analysis results obtained after the Explainanalyze command is executed, which consists of the above three parts, can be saved in a TXT file. These three parts are the query plan, the time spent in each execution stage, and the resource usage. The latter two parts correspond to the macro query indicators of the target query statement.

[0074] In the query plan section, "->" corresponds to a query node. The position and order of "->" for different query nodes reflect the dependencies between them. The query metrics within parentheses () after each query node can be ignored in this embodiment. The query metrics within square brackets [] after each query node are the query node-level metrics of interest in this embodiment, such as: parallelism (dop), execution time (time), number of output rows (rows), memory usage (mem), initialization time (open), time to obtain a batch of data from downstream nodes and perform calculations (get_next), etc. Here, "time" consists of "open" and "get_next". Additionally, each query node also has a corresponding node identifier (id).

[0075] The time consumed in each execution stage can include the total time (TOTALcost) of the actual execution of the target query statement, which includes, but is not limited to, the time consumed in the following specific execution stages: the time spent by the optimizer generating the query plan (Optimizer cost); the time spent converting the query plan generated by the optimizer into the data structure required by the execution engine (Build gang desc table cost); the time spent further preprocessing the query plan generated by the optimizer and sending the query request to the execution engine to start the query stage (Initgangs cost); the time spent in the initialization stage before the actual execution of the query statement, calculated from the completion of the Initgangs step (Start query cost); the time spent from the end of the Start Query stage until all results are returned (Get result cost); the time spent from the end of the Start Query stage until the first batch of data is returned (Get the first block cost), and so on.

[0076] Resource usage can include memory consumption during the execution of the target query statement, total CPU time consumed, amount of data read from disk (physical read bytes), and total read bytes, etc. The total read bytes include both physical reads and data read from the cache.

[0077] To support more detailed query interpretation and analysis, PostgreSQL provides another command, "explain(format JSON, analyze) select xxx", where `select xxx` represents the target query statement, and `format json` indicates that the output text format is JSON. In this case, the command outputs the interpretation and analysis results in JSON format. The JSON format query interpretation and analysis results provided by standard PostgreSQL offer more detailed metrics than the TXT format, allowing for clearer analysis of query execution and easier extensibility. Ease of extensibility means that the definitions of query metrics can be updated according to actual needs because the query plan and query metrics of the query statement output in JSON format are stored separately in different objects, providing a foundation for easy metric expansion.

[0078] For ease of understanding, combined with Figure 3 and Figure 4 The following example illustrates the interpretation and analysis results of the JSON text format corresponding to the target query statement in this embodiment of the invention:

[0079] The interpretation and analysis results in JSON text format include, for example: Figure 3 The query plan shown and as Figure 4 The query metrics shown are divided into two parts.

[0080] Comparing the interpretation and analysis results of the above TXT format, it can be seen that... Figure 3 In the JSON format query plan, the main information includes the node identifier (id) and node type (type) descriptions of the query nodes, as well as the dependencies between different query nodes (represented by the plans field). Some of the "pseudo-query metrics" (such as planrows, Total Cost, etc.) contained therein are not the query metrics output by the explain analyze command that are of interest in this embodiment of the invention, but rather some query metrics output by the explain command. These metrics can be understood as some estimated query metrics, not the actual query metrics generated during the actual execution process.

[0081] exist Figure 3 In the diagram, each query node corresponds to a structure, such as the structure shown in the figure, which consists of the rows from node type to estimated output width. At the end of the structure corresponding to a query node, the structure of the downstream query node is introduced by the field "plans".

[0082] like Figure 4 As shown, query metrics in JSON format are stored in a structure named "Execution Statistics," which includes query node-level metrics and macro-level query metrics at the query statement level. For example, macro-level query metrics include... Figure 4 The bottom of the diagram shows the total cost, optimizer cost, etc.

[0083] The query metrics at the query node level are represented by the children structure shown in the diagram. Each array (represented by each pair of {}) represents a query metric structure corresponding to a query node. Different query nodes are identified by node identifiers (id), and no node type field is included.

[0084] Combination Figure 3 and Figure 4 As the example shows, the statement above that "the query plan and query metrics of the query statement output in JSON format are stored separately" means that the query plan and query metrics are stored in two separate structures, and the query metrics corresponding to the query nodes cannot be obtained directly from the query plan.

[0085] The above provides examples illustrating the interpretation and analysis results of the two different text formats corresponding to the target query statement.

[0086] After obtaining the text-based interpretation and analysis results, the visualization tool parses these results to determine the multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between these nodes, and the various query metrics corresponding to each node. Finally, based on the dependencies between the query nodes, a tree diagram of the query plan is drawn on the target interface, and the various query metrics are bound to each query node in the tree diagram.

[0087] Based on the example of the interpretation and analysis results of the TXT format above, if the interpretation and analysis results of the TXT format are used, then in general, the required parsing results are identified from the interpretation and analysis results of the TXT format according to the preset regular expression rules. The parsing results are multiple query nodes, the dependencies between multiple query nodes, and various query indicators corresponding to each of the multiple query nodes.

[0088] In simple terms, a regular expression rule is a parsing template that defines the field names, symbols, and structural information to be extracted from the analysis results. For example, since the TXT format analysis results do not contain a `nodetype` field, but only use the "->" symbol to directly introduce the name (or type name) of the query node, the regular expression rule needs to explicitly define the names of each query node to be extracted. The regular expression rule also needs to define the extraction rules for the names of the query metrics or key fields (such as `cost`) to be extracted for each query node, such as "xxxxcost:xxxx". This allows for the extraction of multiple query nodes and their corresponding query metrics from the TXT format analysis results. Furthermore, based on the positional relationship of the "->" symbols corresponding to different query nodes, the dependency relationships between the multiple query nodes can be determined for drawing a tree diagram of the query plan.

[0089] As the above analysis process shows, although the TXT format analysis results bind query metrics to query nodes, the TXT format is not easily processed programmatically by visualization tools. A complex parsing logic is required to complete the parsing process. Furthermore, even minor format changes during updates can cause parsing failures when using the original logic. Expanding query metrics in the TXT format is quite difficult. For example, adding a new query metric requires changing the parsing logic—for instance, adding the parsing logic for that query metric to the regular expression rules.

[0090] In the JSON format interpretation and analysis results, the query plan and query metrics are stored separately, which provides a natural convenience for the expansion of query metrics.

[0091] Specifically, the parsing process for the interpretation and analysis results of JSON format can be as follows:

[0092] Define a first structure containing the query plan and a second structure containing various query metrics in a JSON format file;

[0093] Based on the set node identifier indicator string and node dependency indicator string, the identifiers of multiple query nodes and the dependencies between multiple query nodes are identified in the first structure.

[0094] In the second structure, the identifiers of multiple query nodes are located, so that the multiple query indicators corresponding to each of the multiple query nodes are determined in the third structure corresponding to each of the multiple query node identifiers. The third structure corresponding to each query node identifier contains the multiple query indicators corresponding to the corresponding query node.

[0095] Combination Figure 3 and Figure 4 In the example, the first structure and the second structure are the Plan structure and the children structure, respectively. The node identifier indicator string and the node dependency indicator string are the Node ID and the plans, respectively. Thus, in the first structure, based on the identifier corresponding to different query nodes and the plans field, the multiple query nodes contained in the query plan and their dependencies can be determined in the first structure. Among them, the type of query node (as the name) can be obtained according to the correspondence between the node identifier and the node type.

[0096] Since both the first and second structures contain identifiers for each query node, the identifiers of multiple query nodes identified from the first structure can be located within the second structure. Specifically, the third structure (the structure containing the identifier of each query node) within the second structure is the query metric structure corresponding to that query node, which contains various query metrics.

[0097] Based on the above parsing logic, the basic information of the query node (such as identifier and name) can be parsed from the first structure. Based on the identifier of the query node, the query index of the query node can be parsed from the second structure, thereby realizing the binding of the query node with its query index.

[0098] Moreover, based on the above analysis logic, it is known that the specific details of the query indicators are not considered during the analysis process. Therefore, if you want to add or delete some query indicators, you can simply update the execution logic of the explain analyze command without updating the analysis logic that explains the analysis results, thus conveniently expanding the query indicators.

[0099] It should be noted that, as mentioned above, in this embodiment of the invention, the execution logic of the explain analyze command includes not only the calculation process of the query indicators corresponding to the query node, but also the calculation process of the macro query indicators at the level of the target query statement. Therefore, the second structure in the above JSON format interpretation and analysis results also includes macro query indicators.

[0100] At this point, the children structure, which is the second structure, is included in the fourth structure. Figure 4In the example Execution Statistics structure, the part of the fourth structure other than the second structure is the description of the macro query indicators. Based on this, the macro query indicators in text form can be extracted so that the macro query indicators can be graphically displayed in the target interface.

[0101] After identifying multiple query nodes and their dependencies from the textual interpretation and analysis results, such as Figure 5 As shown in the figure, a tree diagram of the query plan can be drawn on the target interface based on the dependencies between query nodes. The tree diagram is represented by the node graphics (or cards) corresponding to each of the multiple query nodes.

[0102] In practical applications, such as Figure 5 As shown, each node graph can include the node's identifier (id) and node name, such as the node graphs #1Project, #2Aggregate, #3Gather, and #4HashJoin shown in the figure.

[0103] Additionally, in a tree diagram, various query metrics can be bound to each query node. In practical applications, optionally, [the following can be done]: Figure 5 Each node diagram illustrates a subset of query metrics corresponding to that query node. When the action to view query metric details is triggered, a query metric details page is displayed, showing various query metrics corresponding to the selected query node. These metrics, among others, include those shown in the node diagrams. Figure 5 The percentages shown in the diagrams—0.00%, 0.00%, 0.28%, and 60.96%—represent the ratio of the individual execution time of the corresponding query node to the total execution time of all query nodes.

[0104] exist Figure 5 Taking the hash join query node as an example, optionally, the query metric details page for this query node can display various query nodes according to different dimensions, such as, but not limited to, the following category tags shown in the image: General (for viewing all query metrics for the query node), Overview (for viewing commonly used key query metrics for the query node), Timing (for viewing time-related query metrics for the query node), and Skew (for users to view data skew metrics for the query node). Users can choose to view the corresponding category of query metrics according to their actual needs. In this way, users can observe the execution status of each query node in the query plan in more detail, thereby better locating and resolving query bottlenecks.

[0105] exist Figure 5In the example, assuming the user selects to view the "Overview" category tag, then as follows: Figure 5 The query metrics shown include: parallelism (dop), execution time (time), number of rows output (rows), memory overhead (mem), etc. Specific metric values ​​are not given in the figure.

[0106] In addition, such as Figure 5 As described above, the target interface for viewing the visual interpretation and analysis results of the target query statement can include two menu options: a first option: Plan, and a second option: Stats. Selecting the first option will display... Figure 5 The tree diagram shown in the image represents the query plan. If the second option is selected, macro-level query metrics for the target query statement will be displayed.

[0107] Therefore, it can be seen that the query metrics displayed through the tree diagram are fine-grained query metrics at the query node level, while the macro-level query metrics of the target query statement are coarse-grained query metrics at the query statement level. For example... Figure 6 As shown in the diagram, the macro-level query metrics of the target query statement can be displayed as two tables, representing the time consumption of each execution stage of the target query statement and the resource consumption during the execution of the target query statement, respectively. Figure 6 In this context, regarding resource consumption, three consumption values ​​(max, avg, min) can be statistically analyzed, representing the maximum, average, and minimum values, respectively. Of course, the display method for macro-level query indicators is not based on... Figure 5 and Figure 6 The representation shown in the image is limited to the examples provided.

[0108] In summary, in this embodiment of the invention, the query plan and query metrics of a query statement can be graphically displayed on the same visual interface, and multi-granularity query metrics can be displayed, revealing query metrics at both coarse and fine granular levels. When interpreting and analyzing results in JSON format, the query plan and query metrics are stored separately. The basic information of the query node (such as the identifier and name of the query node) and the query metrics can be bound through the parsing process. This retains the ability to flexibly add metrics, allowing new query metrics to be easily added without affecting the original parsing logic, and provides good scalability.

[0109] Figure 7 This is a flowchart illustrating a visualization method for query interpretation and analysis results provided in an embodiment of the present invention. This method can be executed by a visualization tool. Figure 7 As shown, the method may include the following steps:

[0110] 701. Obtain the text-based interpretation and analysis results corresponding to the target query statement.

[0111] 702. From the interpretation and analysis results, determine the multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and the various query indicators corresponding to each of the multiple query nodes.

[0112] 703. Based on the dependencies between multiple query nodes, display a tree diagram corresponding to the query plan on the target interface, and bind various query metrics to the multiple query nodes in the tree diagram.

[0113] 704. Based on the preset query metrics corresponding to each of the multiple query nodes, determine the execution performance of the multiple query nodes, and based on the execution performance of the multiple query nodes, determine the display style of the multiple query nodes in the tree diagram.

[0114] In this embodiment, in order to enable users to understand the performance bottlenecks in the execution process of the query plan more directly through the tree diagram of the query plan displayed on the target interface, the execution performance of each query node is determined by combining the query indicators corresponding to each query node, and the node graphs corresponding to different query nodes are displayed differently in the tree diagram according to the execution performance of each query node.

[0115] Generally, the performance of a query node is evaluated from dimensions such as time and memory usage. Therefore, the preset query metrics in step 704 above include, but are not limited to, execution time and memory usage.

[0116] In one optional embodiment, the preset query metrics include the individual execution time of each query node. Therefore, based on the preset query metrics corresponding to each of the multiple query nodes, the execution performance of the multiple query nodes is determined, including:

[0117] For a target query node among multiple query nodes, determine the first execution time of the target query node and the second execution time of the child nodes of the target query node. Based on the difference between the first and second execution times, determine the individual execution time of the target query node. Based on the ratio of the individual execution time of the target query node to the sum of the individual execution times of the multiple query nodes, determine the execution performance of the target query node.

[0118] The first execution time is the time from the start of the query plan to the completion of the target query node, and the second execution time is the time from the start of the query plan to the completion of the child nodes. If the difference is negative, the individual execution time of the target query node is set to a non-negative value.

[0119] In the above embodiments, the individual execution time of a query node is introduced as a query metric. The execution time output by the traditional `explainanalyze` command can be considered to represent the meaning of the first and second execution times mentioned above. That is, the time from the start of the query plan execution to the completion of the target query node execution is taken as the first execution time (cumulative execution time) of the target query node, and the time from the start of the query plan execution to the completion of the child nodes of the target query node execution is taken as the second execution time (cumulative execution time) of the child query nodes. Since the query plan is executed from bottom to top, for most query nodes, their own cumulative execution time is generally greater than that of their child nodes. The aforementioned first execution time is often greater than the second execution time. In this case, the difference between the first and second execution times can be determined as the individual execution time of the target query node, that is, the execution time required to complete the operation of only the target query node.

[0120] However, in reality, there may be cases where the first execution time is less than the second execution time. In this case, to avoid subsequent calculation errors caused by a negative difference, the negative difference is corrected by setting it to a default non-negative value, such as 0.

[0121] It should be noted that if the target query node has multiple child nodes, for example... Figure 5 The Hash Join query node has two child nodes, #6 and #10. The second execution time mentioned above refers to the sum of the cumulative execution times of these multiple child nodes.

[0122] After calculating the individual execution time for each query node in the query plan, the individual execution times of all query nodes are summed. The ratio of the individual execution time of each query node to this summation can be used as an indicator to evaluate the execution performance of that query node.

[0123] The process of determining the execution performance of a query node based on other query metrics is similar in principle. For example, the ratio of the memory consumption of a certain query node to the total memory consumption of all query nodes can be used as the execution performance metric for that query node.

[0124] At least one performance threshold can be preset to determine the display style of query nodes. In general, query nodes with poorer performance are highlighted more prominently, allowing users to clearly perceive which query node has poor performance and quickly locate the performance bottleneck.

[0125] For example, taking the percentage of execution time for a single task as an example, two time percentage thresholds, A1 and A2, can be set, where A1 is greater than A2. If the time percentage of the target query node is greater than A1, it indicates that the target query node is executing very slowly, and the background color of the corresponding node in the tree diagram is set to a dark background. If the time percentage of the target query node is between A1 and A2, it indicates that the target query node is executing relatively slowly, and the background color of the corresponding node in the tree diagram is set to a slightly darker background. If the time percentage of the target query node is less than A2, it indicates that the target query node is executing relatively quickly, and the background color of the corresponding node in the tree diagram is set to a light or transparent background. Figure 8 As shown in the image, assuming that the Hash Join query node accounts for as much as 60.96% of the time, it is very slow and is highlighted with a background color.

[0126] The display style is not limited to the background color distinctions mentioned above. For example, different visual elements such as font color can also be used to distinguish the display of query nodes with different performance levels.

[0127] exist Figure 8 In the context of Hash Join, once a user recognizes that a query node is a performance bottleneck based on its prominent display style and performance metrics, they can view the detailed metrics of that query node to gain a more comprehensive understanding of its query metrics and facilitate targeted optimization.

[0128] Figure 9 This is a flowchart illustrating a visualization method for query interpretation and analysis results provided in an embodiment of the present invention. This method can be executed by a visualization tool. Figure 9 As shown, the method may include the following steps:

[0129] 901. Obtain the text-based interpretation and analysis results corresponding to the target query statement.

[0130] 902. From the interpretation and analysis results, determine the multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and the various query indicators corresponding to each of the multiple query nodes.

[0131] 903. Based on the dependencies between multiple query nodes, display a node dependency thumbnail corresponding to the query plan in the first display area of ​​the target interface, and display a tree diagram corresponding to the query plan in the second display area of ​​the target interface. Bind multiple query metrics to the multiple query nodes in the tree diagram. The node dependency thumbnail is used to display the dependencies between multiple query nodes.

[0132] 904. Based on the preset query metrics corresponding to each of the multiple query nodes, determine the execution performance of the multiple query nodes. Based on the execution performance of the multiple query nodes, determine the display style of the multiple query nodes in the node dependency relationship thumbnail and the tree diagram. The display style of the same query node in the node dependency relationship thumbnail is the same as the display style in the tree diagram.

[0133] 905. In response to the selection operation of the target query node in the node dependency thumbnail, the query indicator details page corresponding to the target query node is displayed in association with the target query node in the tree diagram. The query indicator details page displays a variety of query indicators corresponding to the target query node.

[0134] In practical applications, when the query plan corresponding to the target query statement contains a large number of query nodes, it may not be possible to display the entire tree diagram on a single screen; only a portion of the tree diagram may be visible. To further improve the user-friendliness of the interface, in this embodiment, the query plan is displayed using two different graphical display methods on the aforementioned target interface used for graphically displaying the query plan. Combined with... Figure 10 Let's illustrate with an example.

[0135] like Figure 10 As shown, the first display area (left area) and the second display area (right area) of the target interface display different visualization results of the query plan based on the dependencies between multiple query nodes: a node dependency thumbnail and a tree diagram.

[0136] The node dependency thumbnail is used to show the dependencies between multiple query nodes. It can simply include the name and identifier of the query node, along with an illustration of the dependencies between them. Figure 10 The dependency relationship is illustrated in the form of chained calls.

[0137] In the tree diagram, multiple query nodes are bound to various query metrics, meaning that you can view the various query metrics for each query node through the tree diagram.

[0138] In addition to displaying the above-mentioned node dependency relationship thumbnail and tree diagram, the execution performance of multiple query nodes is determined based on the preset query metrics corresponding to each of the multiple query nodes. Based on the execution performance of multiple query nodes, the display style of multiple query nodes in the node dependency relationship thumbnail and tree diagram is determined. The display style of the same query node in the node dependency relationship thumbnail is the same as the display style in the tree diagram.

[0139] In this way, by observing the display styles of different query nodes in the node dependency thumbnail, users can quickly locate the performance bottleneck node. Optionally, they can select the performance bottleneck node in the tree diagram and trigger the operation of viewing the details of the query metrics. They can then understand the detailed execution status of the performance bottleneck node through the various query metrics bound to it on the tree diagram.

[0140] for example Figure 10 In the example, assuming the performance bottleneck node is the Hash Join query node, the background of the Hash Join query node is highlighted in the node dependency thumbnail, and the background of the query node is also highlighted in the tree diagram.

[0141] In practical applications, the following operation mode can also be set: when a user selects the Hash Join query node in the node dependency thumbnail, the query metric details page of that query node is directly displayed in the tree view of the second display area, such as... Figure 10 As shown in the figure. Among them, Figure 10 The performance evaluation metric shown in the diagram uses the percentage of time spent executing independently, as mentioned above.

[0142] In an optional embodiment, the method further includes: displaying, in a first display area, histograms of multiple query nodes corresponding to a target query metric in association with a node dependency thumbnail, the target query metric being one of a preset type of query metrics used to determine the execution performance of query nodes.

[0143] Since at least one metric can be used to evaluate the performance of a query node, these at least one metric can actually be displayed as labels in the first display area for the user to select. When the user selects a certain metric, the display style of the query node is determined based on the selected metric.

[0144] by Figure 10 Taking the target query metric of individual execution time percentage as an example, in the first display area, the individual execution time percentage for each query node is displayed as the height value of that query node in the histogram. Through the generated histogram, users can intuitively see the actual execution performance metrics of each query node in the first display area. Therefore, based on the content displayed in the first display area, performance bottleneck nodes can be quickly located. For these bottleneck nodes, various query metrics during their detailed execution process can be viewed to understand the detailed execution situation and optimize execution performance.

[0145] Figure 11 This is a flowchart illustrating a visualization method for query interpretation and analysis results provided in an embodiment of the present invention. This method can be executed by a visualization tool. Figure 11 As shown, the method may include the following steps:

[0146] 1101. Obtain the text-based interpretation and analysis results corresponding to the target query statement.

[0147] 1102. From the interpretation and analysis results, determine the multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and the various query indicators corresponding to each of the multiple query nodes.

[0148] 1103. Based on the dependencies between multiple query nodes, display a tree diagram of the query plan on the target interface, and bind various query metrics to the multiple query nodes in the tree diagram.

[0149] 1104. For a target query node among multiple query nodes, determine an indicator group corresponding to at least one query indicator, wherein an indicator group includes the first and second statistical values ​​corresponding to the respective query indicators of multiple executors concurrently executing the target query node during the execution of the target query node.

[0150] 1105. Based on the first and second statistical values ​​contained in the indicator groups corresponding to at least one query indicator, determine the data skew factor corresponding to each of the at least one query indicator. If it is determined that the target query node has data skew based on the data skew factor corresponding to each of the at least one query indicator, add data skew indication information to the target query node in the tree diagram.

[0151] In practice, the execution of the query plan for a target query statement is often carried out in a distributed query system. For example, in real-time data warehouse applications, a server cluster is deployed in the cloud. Each server can be configured with at least one worker node, which runs an execution engine (such as a real-time data warehouse engine) and can execute the query statement.

[0152] For a query plan corresponding to a target query statement, each query node can be associated with a query metric called "parallelism." Parallelism, simply put, refers to how many executors can concurrently execute a query node. For example, for any query node in the query plan (called the target query node), assuming the parallelism of the target query node is 4, then 4 executors concurrently execute the operation task corresponding to the target query node. Concurrent execution means that, assuming the target query node needs to scan a table, this table can be divided into 4 sub-tables, and the 4 executors each execute the scan task of one sub-table. Finally, the scan results of the 4 executors are aggregated to obtain the output result corresponding to the target query node.

[0153] Understandably, if some executors have high loads while others have low loads, then for the execution process of the target query node, if the larger data volume of the sub-table is assigned to the executor with the higher load, the execution time to complete the corresponding scan task will be longer, meaning a longer wait time to obtain the scan results. This phenomenon is called data skew. Simply put, in a distributed query scenario, data skew refers to the uneven distribution of the queried data across different executors, causing some executors to process far more data than others, resulting in excessive load pressure on these executors and significantly longer execution times. Data skew is a common problem in distributed query scenarios; it leads to a degraded overall query performance and is difficult to resolve by simply increasing the size of the executors, requiring proper load balancing.

[0154] Therefore, in this embodiment, for the target query node, it is determined whether there is data skew on a certain query metric, and an alarm is issued when data skew is determined, so that the user can make timely optimizations and adjustments.

[0155] Specifically, for a target query node, firstly, a group of indicators corresponding to at least one query indicator is determined. Each indicator group includes the first and second statistical values ​​corresponding to the respective query indicator for multiple executors concurrently executing the target query node during its execution. The first and second statistical values ​​can be the maximum and minimum values, respectively. Next, based on the first and second statistical values ​​contained in each indicator group corresponding to the at least one query indicator, a data skew factor corresponding to each of the at least one query indicator is determined. For example, the data skew factor can be defined as the ratio of the maximum to the minimum value. Then, if the data skew factor corresponding to each of the at least one query indicator indicates that the target query node exhibits data skew, data skew indication information is added to the target query node in the tree diagram. It can be considered that if the data skew factor corresponding to any query indicator is greater than a set threshold, then the target query node exhibits data skew.

[0156] Combination Figure 12 Example illustration. In Figure 12 In the tree diagram, if the query node "Hash Join" has data skew, as shown in the figure, an icon "?" indicating data skew can be set in the display area of ​​the query node to issue a warning. The specific skew indicator can be viewed by clicking on the query node to display the indicator details page. On the indicator details page, select the "Skew" tab to display the data skew indicator page shown in the figure.

[0157] exist Figure 12The data skew metrics page shows two sets of metrics for query metrics: the get_next_milliseconds metric set and the node_memory_bytes metric set. These represent the time (get_next) to retrieve a batch of data from the child query node and perform calculations, respectively, in milliseconds (milliseconds), and the amount of data read from memory (node_memory), in bytes (bytes).

[0158] exist Figure 12 In this context, we assume that the first and second statistical values ​​included in each indicator group are Max_... and Min_..., respectively. In reality, in addition to these two statistical values, other statistical values ​​such as the average (Avg_...) can also be included.

[0159] Taking the query metric get_next_milliseconds as an example, the corresponding Max statistic refers to the Max value of the get_next time of each of the multiple executors corresponding to the target query node, the corresponding Min statistic refers to the Min value of the get_next time of each of the multiple executors corresponding to the target query node, and the corresponding Avg statistic refers to the Avg value of the multiple get_next times of the multiple executors corresponding to the target query node.

[0160] exist Figure 12 In the query, since the data skew factor corresponding to the query metric get_next_milliseconds for the HashJoin query node is 62 / 2 = 31, which is greater than the set threshold, it is determined that the HashJoin query node has data skew.

[0161] like Figure 12 As shown in the data skewness metrics page, the degree of data skewness varies for different query metrics. For example, the display area corresponding to the metric group with a larger data skewness factor can be highlighted with a darker color so that users can quickly locate the key metric that causes the data skewness.

[0162] The following describes in detail one or more embodiments of a communication device according to the present invention. Those skilled in the art will understand that these devices can all be configured using commercially available hardware components through the steps taught in this solution.

[0163] Figure 13 This is a schematic diagram of a visualization processing device for query interpretation and analysis results provided in an embodiment of the present invention. This device is applied in the aforementioned visualization tool, such as... Figure 13 As shown, the device includes: an acquisition module 11, a determination module 12, and a display module 13.

[0164] Module 11 is used to obtain the textual interpretation and analysis results corresponding to the target query statement.

[0165] The determination module 12 is used to determine, from the interpretation and analysis results, multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and various query indicators corresponding to each of the multiple query nodes.

[0166] Display module 13 is used to display a tree diagram corresponding to the query plan in the target interface according to the dependency relationship between the multiple query nodes, and to bind various query indicators corresponding to each of the multiple query nodes in the tree diagram.

[0167] Optionally, the determining module 12 is further configured to: determine the execution performance of the plurality of query nodes according to the preset types of query indicators corresponding to each of the plurality of query nodes; and determine the display style of the plurality of query nodes in the tree diagram according to the execution performance of the plurality of query nodes.

[0168] Optionally, the display module 13 is further configured to: display a node dependency relationship thumbnail corresponding to the query plan in a first display area of ​​the target interface according to the dependency relationship between the plurality of query nodes, the node dependency relationship thumbnail being used to display the dependency relationship between the plurality of query nodes; wherein the tree diagram is in a second display area of ​​the target interface; and determine the display style of the plurality of query nodes in the node dependency relationship thumbnail according to the execution performance of the plurality of query nodes, wherein the display style of the same query node in the node dependency relationship thumbnail is the same as the display style in the tree diagram.

[0169] Optionally, the display module 13 is further configured to: in response to the selection operation of the target query node in the node dependency thumbnail, display the query indicator details page corresponding to the target query node in association with the target query node in the tree diagram, wherein the query indicator details page displays multiple query indicators corresponding to the target query node.

[0170] Optionally, the display module 13 is further configured to: display, in the first display area, a histogram corresponding to the multiple query nodes under the target query indicator in association with the node dependency thumbnail, wherein the target query indicator is one of the preset types of query indicators.

[0171] Optionally, the preset query metrics include: the individual execution time of a query node. In this case, the determining module 12 is specifically used to: determine, for the target query node among the plurality of query nodes, the first execution time of the target query node and the second execution time of the child nodes of the target query node; wherein, the first execution time is the time from the start of the query plan to the completion of the target query node's execution, and the second execution time is the time from the start of the query plan to the completion of the child nodes' execution; determine the individual execution time of the target query node based on the difference between the first execution time and the second execution time; wherein, if the difference is negative, the individual execution time of the target query node is determined to be a set non-negative value; determine the execution performance of the target query node based on the ratio of the individual execution time of the target query node to the sum of the individual execution times of the plurality of query nodes.

[0172] Optionally, the determining module 12 is further configured to: for a target query node among the plurality of query nodes, determine an indicator group corresponding to at least one query indicator, wherein an indicator group includes a first statistical value and a second statistical value corresponding to the corresponding query indicator when multiple executors concurrently executing the target query node execute the target query node; determine a data skew factor corresponding to each of the at least one query indicator based on the first statistical value and the second statistical value contained in the indicator group corresponding to each of the at least one query indicator; if it is determined that the target query node has data skew based on the data skew factor corresponding to each of the at least one query indicator, then add data skew indication information to the target query node in the tree diagram.

[0173] Optionally, the interpretation and analysis results may also include macro query indicators corresponding to the target query statement, and the display module 13 is further used to: graphically display the macro query indicators in the target interface.

[0174] Optionally, the acquisition module 11 is specifically used for: if the interpretation and analysis result is a JSON format file, then determining a first structure containing the query plan and a second structure containing the multiple query indicators in the JSON format file; identifying the identifiers of the multiple query nodes and the dependencies between the multiple query nodes in the first structure according to the set node identifier indication string and node dependency indication string; locating the identifiers of the multiple query nodes in the second structure, so as to determine the multiple query indicators corresponding to each of the multiple query nodes in the third structure corresponding to each of the identifiers of the multiple query nodes, wherein the third structure corresponding to the identifier of each query node contains the multiple query indicators corresponding to the corresponding query node.

[0175] Figure 13 The device shown can perform the steps provided in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0176] This invention also provides an electronic device, such as... Figure 14 As shown, it may include: a processor 21, a memory 22, and a communication interface 23. The memory 22 stores executable code, which, when executed by the processor 21, implements the visualization processing method for query interpretation and analysis results as described in the preceding embodiments.

[0177] In addition, embodiments of the present invention provide a non-transitory machine-readable storage medium on which executable code is stored. When the executable code is executed by a processor in an electronic device, the visualization processing method for query interpretation and analysis results provided in the foregoing embodiments can be implemented.

[0178] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0179] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. The present invention can take the form of a computer program product implemented 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.

[0180] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for visualizing query interpretation and analysis results, characterized in that, The method includes: Obtain the text-based interpretation and analysis results corresponding to the target query statement; From the interpretation and analysis results, we determine multiple query nodes that constitute the query plan corresponding to the target query statement, the dependencies between the multiple query nodes, and the various query indicators corresponding to each of the multiple query nodes. Based on the dependencies between the multiple query nodes, a tree diagram corresponding to the query plan is displayed on the target interface, and various query metrics corresponding to each of the multiple query nodes are bound to the tree diagram. If the interpretation and analysis results are in JSON format, then a first structure containing the query plan and a second structure containing the various query metrics are determined in the JSON format file. Based on the set node identifier indication string and node dependency indication string, the identifiers of the multiple query nodes and the dependencies between the multiple query nodes are identified in the first structure; The identifiers of the plurality of query nodes are located in the second structure, and the various query indicators corresponding to the plurality of query nodes are determined in the third structure corresponding to each of the identifiers of the plurality of query nodes. The third structure corresponding to the identifier of each query node contains the various query indicators corresponding to the corresponding query node.

2. The method according to claim 1, characterized in that, The method further includes: The execution performance of the multiple query nodes is determined based on the preset query metrics corresponding to each of the multiple query nodes. The display style of the multiple query nodes in the tree diagram is determined based on their execution performance.

3. The method according to claim 2, characterized in that, The method further includes: Based on the dependencies between the multiple query nodes, a node dependency thumbnail corresponding to the query plan is displayed in the first display area of ​​the target interface. The node dependency thumbnail is used to display the dependencies between the multiple query nodes; wherein, the tree diagram is in the second display area of ​​the target interface. Based on the execution performance of the multiple query nodes, the display style of the multiple query nodes in the node dependency relationship thumbnail is determined, wherein the display style of the same query node in the node dependency relationship thumbnail is the same as the display style in the tree diagram.

4. The method according to claim 3, characterized in that, The method further includes: In response to the selection operation of the target query node in the node dependency thumbnail, the query indicator details page corresponding to the target query node is displayed in association with the target query node in the tree diagram. The query indicator details page displays a variety of query indicators corresponding to the target query node.

5. The method according to claim 3, characterized in that, The method further includes: In the first display area, histograms corresponding to the multiple query nodes under the target query indicator are displayed in association with the node dependency thumbnail, where the target query indicator is one of the preset types of query indicators.

6. The method according to any one of claims 2 to 5, characterized in that, The preset query metrics include: the individual execution time of the query node; The step of determining the execution performance of the multiple query nodes based on preset query metrics corresponding to each of the multiple query nodes includes: For the target query node among the plurality of query nodes, a first execution time for the target query node and a second execution time for the child nodes of the target query node are determined; wherein, the first execution time is the time from the start of the query plan to the completion of the target query node, and the second execution time is the time from the start of the query plan to the completion of the child nodes. The individual execution time of the target query node is determined based on the difference between the first execution time and the second execution time; wherein, if the difference is negative, the individual execution time of the target query node is determined to be a set non-negative value. The execution performance of the target query node is determined by the ratio of the individual execution time of the target query node to the sum of the individual execution times of the multiple query nodes.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: For a target query node among the plurality of query nodes, an indicator group corresponding to at least one query indicator is determined, wherein an indicator group includes a first statistical value and a second statistical value corresponding to the corresponding query indicator when multiple executors concurrently execute the target query node during the execution of the target query node; Based on the first and second statistical values ​​contained in the indicator groups corresponding to the at least one query indicator, determine the data skew factor corresponding to each of the at least one query indicator. If it is determined that the target query node has data skew based on the data skew factor corresponding to each of the at least one query indicator, then data skew indication information is added to the target query node in the tree diagram.

8. The method according to any one of claims 1 to 5, characterized in that, The interpretation and analysis results also include macro-level query indicators corresponding to the target query statement; The method further includes: The macro query indicators are displayed graphically on the target interface.

9. An electronic device, characterized in that, include: The system includes a memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, it performs a visualization processing method for query interpretation analysis results as described in any one of claims 1 to 8.

Images