Execution plan node management method and device, equipment, storage medium and program product

Abstract

The invention provides an execution plan node management method and device, equipment, a storage medium and a program product, and relates to the technical field of computers. The method comprises the following steps: traversing an execution plan tree of a database, and creating a probe for each execution plan node in the execution plan tree; registering a probe of each execution plan node to a memory context corresponding to each execution plan node, wherein each memory context is associated with a memory allocation event of each execution plan node; and recording memory allocation data and memory release data of the memory context in real time through the probe, and generating a memory consumption record of each execution plan node. The method is used for achieving the effect of improving the real-time performance and accuracy of detection.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an execution plan node management method, apparatus, device, storage medium, and program product. Background Technology

[0002] With the exponential growth of business complexity and data volume, enterprise database systems need to handle massive amounts of Structured Query Language (SQL) data under high concurrency scenarios. Memory consumption during SQL execution is a key factor affecting system performance. When executing complex queries, operations such as sorting and hash joins can lead to memory overflows, causing query interruptions or system crashes. Therefore, proper management of execution plan nodes in the database is crucial.

[0003] Currently, existing execution plan node management methods primarily rely on process-level memory monitoring. These methods obtain memory usage information for each process within a database instance through operating system interfaces or built-in database views. However, existing execution plan node management methods can only calculate the total memory consumption of processes, resulting in poor real-time performance and accuracy. Summary of the Invention

[0004] This application provides an execution plan node management method, apparatus, device, storage medium, and program product to improve the real-time performance and accuracy of detection.

[0005] Firstly, this application provides a method for managing execution plan nodes, including:

[0006] Traverse the execution plan tree of the database and create a probe for each execution plan node in the execution plan tree;

[0007] The probe of each execution plan node is registered to the memory context corresponding to each execution plan node, and each memory context is associated with the memory allocation event of each execution plan node;

[0008] The probe records the memory allocation and release data of the memory context in real time, generating memory consumption records for each execution plan node.

[0009] In one possible implementation, each probe includes at least one of the following information: node identification information, memory statistics information, time statistics information, and context information; wherein, the node identification information is used to identify the object detected by the probe, the memory statistics information is used to record dynamic memory usage data, the time statistics information is used to record the start and end execution times of the object, and the context information is used to locate the module and stage of memory usage; and / or,

[0010] The execution plan tree is obtained by parsing an SQL statement. Each execution plan node is a database operation operator, and each execution plan node includes one of the following: scan node, join node, aggregation node, sort node; and / or,

[0011] The memory context is a tree structure, arranged from top to bottom. The first layer is the root context of the entire database process, the second layer is the query context allocated to each query, the third layer is the executor state context, the fourth layer is the execution plan node context, and the fifth layer is the private context of each execution plan node.

[0012] In one possible implementation, the step of recording memory allocation and release data of the memory context in real time through the probe, and generating memory consumption records for each execution plan node, includes:

[0013] Data collection is triggered based on the memory allocation event of the memory context, and the following information of the memory allocation event is recorded in the memory consumption record: memory allocation size, memory allocation timestamp, memory release size, memory release timestamp, and memory context identifier.

[0014] In one possible implementation, the memory consumption records are divided into a core statistics table and a time series table according to the time dimension. The core statistics table stores snapshot data of the node's lifecycle, and the time series table stores waveform data of memory changes. The method further includes at least one of the following:

[0015] Predict future memory peak values ​​based on the periodic patterns of the memory waveform data;

[0016] Based on the mutation point detection of the aforementioned memory waveform data, the risk of memory overflow is predicted.

[0017] The long-term memory growth trend is predicted based on trend line fitting of the memory waveform data.

[0018] In one possible implementation, a dynamic performance view is displayed based on the memory consumption records; the dynamic performance view includes a real-time detection view and a historical analysis view, the real-time detection view is used to display the currently executing queries and the memory consumption of each node, and the historical analysis view is used to display the intelligent diagnostic results obtained by intelligently diagnosing the database based on historical data.

[0019] In one possible implementation, the method further includes: displaying a parameter configuration interface;

[0020] The user's personalized settings are received based on the parameter configuration interface;

[0021] The parameter configuration interface shall include at least the following:

[0022] The master switch setting control allows users to enable or disable the entire memory detection function globally with a single click.

[0023] The sampling and frequency control settings are used to set the sampling time interval and the minimum memory threshold.

[0024] Resource protection mechanism settings control, used to set the maximum number of detection probes per query;

[0025] The data lifecycle settings control is used to set the number of days data is automatically retained;

[0026] The intelligent function switch setting control allows users to choose whether to enable the automatic optimization suggestion generation function and whether to obtain intelligent diagnostic results.

[0027] In one possible implementation, the method further includes: dynamically adjusting the data acquisition frequency based on the memory allocation size recorded in the memory consumption record; wherein, the sampling frequency is increased when the memory allocation size exceeds a preset threshold, and the sampling frequency is decreased when the allocation size is lower than the preset threshold.

[0028] Secondly, this application provides an execution plan node management device, comprising:

[0029] A module is created to traverse the execution plan tree of the database and create a probe for each execution plan node in the execution plan tree;

[0030] The registration module is used to register the probe of each execution plan node to the memory context corresponding to each execution plan node, and each memory context is associated with the memory allocation event of each execution plan node;

[0031] The generation module is used to record the memory allocation data and memory release data of the memory context in real time through the probe, and generate the memory consumption record of each execution plan node.

[0032] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0033] The memory stores computer-executed instructions;

[0034] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0035] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0036] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0037] This application provides an execution plan node management method, apparatus, device, storage medium, and program product. By traversing the execution plan tree of the database, a probe is created for each execution plan node in the tree, laying the foundation for subsequent memory allocation operations. The probe for each execution plan node is registered to the corresponding memory context, and each memory context is associated with the memory allocation event of each execution plan node, improving the accuracy of locating the source of memory consumption. By recording the memory allocation and release data of the memory context in real time through the probe, a memory consumption record for each execution plan node can be generated, improving the real-time performance and accuracy of detection. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0039] Figure 1 A flowchart illustrating an execution plan node management method provided in this application;

[0040] Figure 2 A schematic diagram of the architecture of an execution plan node management system provided in this application;

[0041] Figure 3 A flowchart illustrating the initialization preparation process in an execution plan node management method provided in this application;

[0042] Figure 4 A flowchart illustrating the execution-time detection and data collection method in the execution plan node management method provided in this application;

[0043] Figure 5 A schematic diagram of the structure of an execution plan node management device provided in this application;

[0044] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application.

[0045] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0047] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0048] 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 this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0049] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0050] First, let's explain some of the terms used in this application:

[0051] Structured Query Language (SQL) is a standardized programming language used to interact with relational databases for querying, updating, defining, and controlling data.

[0052] With the exponential growth of business complexity and data volume, enterprise database systems need to handle massive amounts of Structured Query Language (SQL) data under high concurrency scenarios. Memory consumption during SQL execution is a key factor affecting system performance. When executing complex queries, operations such as sorting and hash joins can lead to memory overflows, causing query interruptions or system crashes. Therefore, proper management of execution plan nodes in the database is crucial.

[0053] The existing methods for managing execution plan nodes mainly include the following:

[0054] 1. Process-level memory detection. This method obtains the memory usage of each process in the database instance through operating system interfaces or built-in database views. However, this method can only count the total memory consumption of processes and cannot distinguish the source of memory consumption (such as sorting operations, hash joins, etc.), nor can it be linked to the execution plan node of a specific SQL statement, resulting in poor accuracy of the detection data.

[0055] 2. Shared Memory and Local Memory Statistics. This method relies on statistical interfaces provided by some databases to analyze shared memory and local memory. However, this method only reflects the macroscopic memory allocation and cannot refine the memory consumption patterns of individual SQL executions, resulting in poor real-time performance of the detected data.

[0056] 3. Post-execution analysis of the execution plan. This method obtains performance statistics after SQL execution, including some memory consumption data, by executing commands. However, this method requires manual triggering and can only obtain static results after execution, failing to monitor dynamic memory changes in real time during execution, resulting in poor real-time performance and accuracy.

[0057] Therefore, existing execution plan node management methods suffer from poor real-time performance and accuracy. Considering these issues, this application proposes an execution plan node management method at the database execution engine level, embedding a detection probe and a memory context association mechanism. This method improves both real-time performance and accuracy.

[0058] The execution entity of this execution plan node management method can be, for example, a management system. Optionally, the management system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the management system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the management system.

[0059] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments.

[0060] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0061] Figure 1 This is a flowchart illustrating an execution plan node management method provided in this application. Figure 1 As shown, the method includes:

[0062] S101, traverse the execution plan tree of the database and create a probe for each execution plan node in the execution plan tree.

[0063] For example, an execution plan node can be an operation unit in the execution plan generated after database query optimization. For instance, an execution plan node could be a sorting, hash join, aggregation, etc.

[0064] For example, the probe may be a sensor unit embedded in the node that performs the call reception.

[0065] Optionally, the management system can obtain structured execution plan data through a database interface, convert the structured data into a tree object in memory, and reconstruct the hierarchical relationship of the execution plan tree. The management system can either access the root node first and then recursively traverse all nodes, or it can traverse the execution plan tree hierarchically from root to leaf. For example, it can traverse the root node first, then the first-level child nodes, and then the second-level child nodes. After the traversal is complete, the total number of nodes traversed is determined based on the total number of nodes in the execution plan tree.

[0066] Optionally, the management system can select general probes to collect node name, node type, start execution time, and end execution time, etc., and can also select connection-type node probes to collect the number of linked rows, the number of matched rows, the hash table size, and the number of loops, etc.

[0067] Optionally, the management system can instantiate corresponding probes based on probe type and node type. When traversing the execution plan nodes of the execution plan tree in the database, it can create corresponding probes according to the node type and establish a mapping table between node names and corresponding probes.

[0068] S102, register the probe of each execution plan node to the memory context corresponding to each execution plan node, and each memory context is associated with the memory allocation event of each execution plan node.

[0069] In some embodiments, each probe includes at least one of the following information: node identification information, memory statistics information, time statistics information, and context information; wherein the node identification information is used to identify the object detected by the probe, the memory statistics information is used to record dynamic memory usage data, the time statistics information is used to record the start and end execution times of the object, and the context information is used to locate the module and stage of memory usage; and / or,

[0070] This execution plan tree is obtained by parsing an SQL statement. Each node in the execution plan represents a database operation operator. Each execution plan node includes one of the following: scan node, join node, aggregation node, sort node; and / or,

[0071] The memory context is a tree structure, arranged from top to bottom. The first level is the root context of the entire database process, the second level is the query context allocated for each query, the third level is the executor state context, the fourth level is the execution plan node context, and the fifth level is the private context of each execution plan node.

[0072] For example, node identification information can be metadata that uniquely identifies the object being detected by the probe.

[0073] For example, memory statistics can be node memory usage data dynamically collected by probes. These statistics may include the amount of memory allocated or released, current usage, peak memory usage, and the number of allocation events.

[0074] For example, time statistics can be the node execution timing data recorded by the probe. For instance, time statistics may include the start execution time, end execution time, and execution time.

[0075] For example, context information can be auxiliary data for locating dimensions of memory usage. For instance, context information may include the module to which it belongs, the execution phase, and the memory context level.

[0076] For example, the first layer, the root context of the entire database process, can be a global memory management unit covering the entire database process. The second layer, the query context allocated to each query, can be a memory management unit specifically allocated to a single SQL query. The third layer, the executor state context, can be a memory management unit bound to the running state of the database executor. The fourth layer, the execution plan node context, can be the core memory management unit of a single execution plan node. The fifth layer, the private context of each execution plan node, can be a temporary memory management unit specific to the execution plan node, managing the node's private temporary memory.

[0077] Optionally, the management system can maintain a tree-like relationship through parent-child references, designing hierarchical memory context classes. For example, this could include a context identity document (ID), hierarchy, associated node IDs, an event callback list, and probe references.

[0078] Optionally, when the database process starts, the management system can create a global root context, parse the SQL to generate an execution plan tree, create a query context for the SQL, and attach it to the root context. During executor initialization, an executor state context is created and attached to the query context. By traversing the execution plan tree, a node context is created for each execution plan node and attached to the executor state context.

[0079] Optionally, the management system can create additional private contexts for nodes requiring private execution plan memory and attach them to the corresponding execution plan node's private context. After construction, the management system can verify the mapping relationship between node IDs and context IDs to ensure that each execution plan node corresponds to only one fourth-level context.

[0080] Optionally, for different types of execution plan nodes, the management system can initialize execution plan node probe instances with multi-dimensional information. For example, multi-dimensional information may include node identifier, memory statistics, time statistics, and context information.

[0081] Optionally, the management system can use callback functions to bind the initialized probes to the fourth or fifth level memory context of the execution plan node, and at the same time establish a mapping table between probe IDs and context IDs to record the registration status of the probes.

[0082] Optionally, the management system can intercept memory allocation or deallocation operations through database kernel hook functions, parsing the execution plan node ID, memory size, and operation type to which the operation belongs. Based on the node ID, it queries the global context mapping table to locate the fourth or fifth level memory context of the corresponding node. When an event is triggered, it calls the probe callback function registered within the context, carrying the node ID, context level, and operation timestamp in the memory allocation event, thus associating each memory context with the memory allocation event of each execution plan node.

[0083] By using the above method, the detection level is shifted from the process level to the node level by registering the probe to the memory context dedicated to the execution plan node, thereby improving the accuracy of memory problem detection.

[0084] S103, the probe records the memory allocation and release data of the memory context in real time, and generates the memory consumption record of each execution plan node.

[0085] As one possible implementation, the management system can trigger data collection based on the memory allocation event of the memory context and record the following information of the memory allocation event in the memory consumption record: memory allocation size, memory allocation timestamp, memory release size, memory release timestamp, and memory context identifier.

[0086] For example, the memory allocation size can be the number of bytes of memory actually requested from the database kernel when the memory context triggers a memory request event.

[0087] For example, a memory allocation timestamp can be a high-precision time identifier of when a memory request event occurs.

[0088] For example, the memory release size can be the number of bytes of memory actually returned to the database kernel when the memory context triggers a memory release event.

[0089] Optionally, the management system can predefine a trigger rule table. If a memory allocation or memory release event is detected, data collection is triggered. If a memory allocation event of a specified memory context is detected, data collection of the specified memory context is triggered. If the memory allocation size or memory release size is detected to be greater than a preset threshold, data collection is performed.

[0090] Optionally, the management system can register memory allocation event monitors with the database kernel, bind the monitors to a trigger rule table, and monitor memory operations of all memory contexts in real time. When an event occurs, the management system can automatically verify whether the event meets the trigger rules based on the monitor. If it meets the trigger rules, the data collection process can be triggered; otherwise, no data collection operation will be performed.

[0091] Optionally, the management system can extract information such as memory allocation size, memory allocation timestamp, memory release size, memory release timestamp, and memory context identifier by parsing the memory context and event metadata, and perform non-empty and validity checks on the extracted information.

[0092] For example, the management system can check if the timestamp is not 0, if the context identifier is not an empty string, and if the memory size is greater than 0. If the timestamp is 0, the context identifier is an empty string, or the memory size is less than 0, the management system can determine that the verification has failed and trigger two retries. If the two retries fail, it is marked as an abnormal event and recorded in a temporary exception table.

[0093] Optionally, the management system can convert the verified information into a unified structured format and store it based on a time-series database, while also creating indexes for memory context identifiers, allocation timestamps, and release timestamps. It can also store the time-series database data into a relational database according to daily statistics. After writing is complete, the system checks whether the data was successfully stored by querying the record ID; if storage is missing, it triggers three automatic retries. If all three retries fail, an alarm is pushed to the operations and maintenance platform.

[0094] Optionally, the management system can also configure a retention period for memory consumption records, and clean up and archive expired memory consumption record data that exceeds the retention period. Before cleaning up expired memory consumption record data, the management system can also verify whether the record has completed the allocation and release process. If the above process has not been completed, the retention period of incomplete core business records can be extended.

[0095] By using the above method, data collection is triggered based on memory allocation events in the memory context, and the following information of the memory allocation event is recorded in the memory consumption record: memory allocation size, memory allocation timestamp, memory release size, memory release timestamp, and memory context identifier. This can improve data collection efficiency, thereby improving the real-time performance and accuracy of detection.

[0096] As one possible implementation, the management system can divide the memory consumption record into a core statistics table and a time series table according to the time dimension. The core statistics table stores snapshot data of the node's life cycle, and the time series table stores waveform data of memory changes.

[0097] Optionally, the management system can predict future memory peaks based on the periodic patterns of the memory waveform data, and can also detect and predict memory overflow risks based on abrupt changes in the memory waveform data. Furthermore, it can predict long-term memory growth trends based on trend line fitting of the memory waveform data.

[0098] Optionally, the management system can pre-set snapshot timestamps for node lifecycles based on a time dimension. For example, snapshot timestamps could be node or memory context creation, reaching a new peak in memory usage, completion of memory release, or manual snapshot triggering. When a snapshot timetamp is reached, the corresponding data is extracted from the memory consumption records and written to the core statistics table in real time.

[0099] Optionally, the system can aggregate memory data for a given time slice from the memory consumption record cache based on a preset time granularity and write it in batches to the time series table. If a memory allocation or release event is triggered but the scheduled sampling point has not yet arrived, the system can add a new data entry.

[0100] Optionally, the management system can periodically rebuild the indexes of memory context identifiers and associated execution plan node IDs based on the core statistics table, and construct partitioned indexes of tags and time ranges based on the time series table. The management system can also set retention periods for the core statistics table and the time series table; after the retention period expires, data will be automatically deleted and recorded in the deletion log.

[0101] For example, a periodic pattern could be a pattern in which memory usage fluctuates regularly over time.

[0102] For example, mutation point detection could be used to identify sudden increases or decreases in memory usage.

[0103] Optionally, the management system can read memory waveform data for a specified period from a time series table, identify the period type of memory fluctuations through autocorrelation analysis and Fourier transform, and calculate the period length. For example, the period length could be a daily period of 24 hours. Based on the identified period, the management system can extract the memory peak value, the peak value's timestamp, and the corresponding business scenario for each period.

[0104] Optionally, the management system can train a cycle prediction model based on historical 30-day cycle peak data, cycle length, historical peak values, and peak period business query rates, and output the memory peak value and corresponding confidence interval for the next 7 days.

[0105] Optionally, the management system can set a mutation threshold based on the system's memory limit, calculate the memory mean using a fixed window, and detect mutations in the mean using an incremental window. If the difference between the fixed window and the incremental window exceeds the mutation threshold, the management system can identify it as a mutation point. The management system can also set a dynamic threshold based on the standard deviation of historical memory waveform data.

[0106] Optionally, the management system can assign weighted coefficients based on the mutation magnitude, mutation duration, and historical spillover probabilities after mutations, and calculate the aforementioned weighted sum to obtain an spillover risk score. If the spillover risk score is less than or equal to 30, the management system can determine it as low spillover risk; if the spillover risk score is greater than 30 but less than 70, the management system can determine it as medium spillover risk; if the spillover risk score is greater than or equal to 70, the management system can determine it as high spillover risk. If it is a high spillover risk, the management system can immediately push an alarm and output emergency suggestions.

[0107] Optionally, the management system can use an exponential moving average algorithm to filter short-term fluctuation noise, process memory waveform data in segments according to the time dimension, and identify growth characteristics at different stages. Based on the above growth characteristics and historical memory waveform data, a trend line fitting model is trained.

[0108] Optionally, the management system can use the trend line fitting model and time series table described above to obtain the predicted long-term growth trend and predicted values ​​of key nodes. The management system can also combine the prediction results to output phased expansion suggestions.

[0109] Using the methods described above, the memory consumption record is divided into a core statistics table and a time series table according to the time dimension, providing a data foundation for capacity planning and performance prediction, and improving system maintainability. Predicting future memory peaks based on the periodic patterns of this memory waveform data can improve resource utilization. Detecting abrupt changes in the memory waveform data and predicting memory overflow risks can improve system stability. Fitting trend lines from the memory waveform data to predict long-term memory growth trends avoids cost waste and ensures business continuity.

[0110] In this embodiment, the execution plan tree of the database is traversed, and a probe is created for each execution plan node in the tree, laying the foundation for subsequent memory allocation operations. The probe for each execution plan node is registered to the corresponding memory context, and each memory context is associated with the memory allocation event of each execution plan node, improving the accuracy of locating the source of memory consumption. By recording the memory allocation and release data of the memory context in real time through the probe, a memory consumption record for each execution plan node can be generated, improving the real-time performance and accuracy of the detection.

[0111] In some embodiments, the management system can display a dynamic performance view based on the memory consumption record. The dynamic performance view includes a real-time detection view and a historical analysis view. The real-time detection view is used to display the currently executing queries and the memory consumption of each node. The historical analysis view is used to display the intelligent diagnostic results obtained by intelligently diagnosing the database based on historical data.

[0112] Optionally, the management system can obtain the metadata of currently executing queries through the database kernel interface based on a preset collection frequency. By associating the query ID with the execution plan node ID in the aforementioned query metadata, the system can extract the memory consumption record of the corresponding execution plan node from the time series table.

[0113] Optionally, the management system can construct a multi-dimensional real-time monitoring view based on memory consumption records. For example, this multi-dimensional real-time monitoring view may include a query overview panel, a node details panel, and a memory context details panel. The query overview panel may include the query ID, SQL statement, execution duration, and execution status. The node details panel may display the execution plan tree corresponding to the query, indicating the current memory usage and memory percentage of each node. The memory context details panel may display the context identifier of the fourth or fifth level memory context corresponding to the node, the cumulative allocated or released memory, and the corresponding timestamp.

[0114] Optionally, the management system can extract corresponding data from the core statistics table and time series table based on the user's selection of the time range, query type, and node type. Based on historical memory consumption records and the aforementioned data, an intelligent diagnostic algorithm is used to analyze the data and construct a historical analysis view.

[0115] For example, the historical analysis view may include a diagnostic report panel and a historical trend visualization panel. The diagnostic report panel may include the diagnostic time range, high memory consumption queries, number of abnormal events, memory growth trend conclusions, and a list of optimization suggestions. The historical trend visualization panel may include peak memory trends, abnormal event distribution, and node memory percentage distribution.

[0116] By using the above method, a dynamic performance view can be displayed based on the memory consumption record, which can intuitively detect memory performance and improve response speed.

[0117] As one possible implementation, the management system can display a parameter configuration interface. Then, it can receive personalized settings from the user based on this interface. This parameter configuration interface should include at least the following:

[0118] The master switch setting control allows users to enable or disable the entire memory detection function globally with a single click.

[0119] The sampling and frequency control settings are used to set the sampling time interval and the minimum memory threshold.

[0120] Resource protection mechanism settings control, used to set the maximum number of detection probes per query;

[0121] The data lifecycle settings control is used to set the number of days data is automatically retained;

[0122] The intelligent function switch setting control allows users to choose whether to enable the automatic optimization suggestion generation function and whether to obtain intelligent diagnostic results.

[0123] Optionally, the management system can adopt a hierarchical layout, dividing areas according to function. For example, it may include a global control area, a data acquisition rules area, a resource restriction area, a data management area, and an intelligent function area. The management system can also provide descriptive text for each control in each area and display the current parameter value in real time.

[0124] Optionally, the management system can use a slider switch to set the master switch control. For the sampling and frequency control settings control, the management system can input the sampling time interval in the numeric input box and select the minimum memory threshold from the drop-down box. For the resource protection mechanism settings control, the maximum number of probes per query can be limited through the numeric input box. For the data lifecycle settings control, the data lifecycle can be selected through the drop-down box, and can also be customized by associating it with the input box. For the intelligent function switch settings control, two independent checkboxes can be set, labeled "Enable automatic optimization suggestion generation" and "Enable intelligent diagnostic result acquisition," respectively.

[0125] Optionally, users can complete parameter configuration through the aforementioned controls in the parameter configuration interface. The management system can then verify the validity of the input parameters based on the configuration change log generated from the user's personalized settings. If the verification fails, the management system can highlight the error control and prevent the settings from being submitted until the parameters are corrected and valid.

[0126] For example, the management system can verify whether the sampling time interval is within the range of 10 milliseconds to 1000 milliseconds and is an integer multiple of 10. If the verification fails, it will prompt "Please enter a valid sampling time interval". The management system can also verify whether the minimum memory threshold is a preset option or a custom positive integer. If the verification fails, it will prompt "Please select or enter a valid memory threshold".

[0127] Optionally, the management system can also verify whether the maximum number of probes is within the range of 10-100 and is an integer multiple of 10. If the verification fails, the system will prompt "Please enter the number of valid probes". The management system can also verify whether the data retention period is greater than or equal to 1 and less than or equal to 365. If the verification fails, the system will prompt "Please enter the number of valid retention days (1-365 days)".

[0128] By displaying the parameter configuration interface using the methods described above, the operational threshold can be lowered and operational efficiency improved. This parameter configuration interface also receives personalized settings from users, enhancing adaptability to different scenarios.

[0129] As one possible implementation, the management system can dynamically adjust the data collection frequency based on the memory allocation size recorded in the memory consumption log. Specifically, the sampling frequency is increased when the memory allocation size exceeds a preset threshold, and decreased when the allocation size is below the preset threshold.

[0130] For example, the sampling frequency can be the number of memory allocation events recorded per unit of time.

[0131] Optionally, the management system can set static thresholds through a parameter configuration interface, such as a low threshold of 100 bytes, a medium threshold of 1000 bytes, and a high threshold of 2000 bytes. It can also dynamically adjust the thresholds by analyzing historical memory allocation data daily and calculating the mean and standard deviation.

[0132] Optionally, the management system can set rules for adjusting the sampling frequency in a step-by-step manner based on the memory allocation size and preset thresholds. For example, if the memory allocation size range of the memory consumption record is less than or equal to the low threshold, the management system can set the sampling frequency to a low frequency, such as once every 500 milliseconds.

[0133] For example, if the memory allocation size range of the memory consumption record is greater than the low threshold and less than the medium threshold, the management system can set the sampling frequency to a medium frequency, such as once every 100 milliseconds; if the memory allocation size range of the memory consumption record is greater than the medium threshold and less than the high threshold, the management system can set the sampling frequency to a high frequency, such as once every 50 milliseconds; if the memory allocation size range of the memory consumption record is greater than the high threshold, the management system can set the sampling frequency to the highest frequency, such as once every 20 milliseconds.

[0134] Optionally, when the memory allocation size enters the high threshold range, the management system can increase the sampling frequency from low to medium frequency; when the memory allocation size remains below a certain threshold for more than the state retention time, the management system can reduce the sampling frequency from high to low frequency.

[0135] Using the above method, the sampling frequency is increased when the memory allocation size exceeds a preset threshold to ensure that key memory patterns are fully captured; when the allocation size is below the preset threshold, the sampling frequency is decreased to reduce redundant data generation. By dynamically adjusting the data acquisition frequency based on the memory allocation size recorded in the memory consumption log, detection efficiency is improved, thereby enhancing the real-time performance and accuracy of the detection.

[0136] Figure 2 This is a schematic diagram of the architecture of an execution plan node management system provided in this application. Figure 2 As shown, the system includes: an application layer interface, a statistical collection layer, a detection probe layer, and a kernel layer.

[0137] Optionally, the application layer interface can provide visualization and interactive functions to users and operations personnel. This may include dynamic performance views for real-time display of memory consumption; an optimization suggestion generation module to provide users with specific SQL tuning solutions; and historical data analysis functions to support querying and reviewing long-term memory usage trends.

[0138] Optionally, the statistical collection layer can act as a data processing hub, responsible for receiving raw data from the lower layers and performing aggregation and processing. Through a built-in sampling control mechanism, a balance is struck between data accuracy and system overhead. It also features a threshold alarm function to promptly issue notifications when memory usage is abnormal.

[0139] Optionally, the detection probe layer can be directly embedded into the database execution engine to perform detection at various key nodes of SQL execution (such as sorting, hash join, etc.), record the activities of different memory contexts, and perform real-time, high-frequency data collection.

[0140] Optionally, the kernel layer can be the foundation of the entire system, utilizing and extending the database's own core modules, including an executor that executes queries, a memory manager responsible for memory allocation and reclamation, and a planner that generates execution plans.

[0141] Optionally, this layered architecture ensures a complete closed loop from data acquisition and processing to presentation, enabling a comprehensive understanding of memory consumption during SQL execution from macro to micro levels.

[0142] Optionally, the core component design revolves around two key components: a memory monitor probe and an execution node detector. The memory monitor probe serves as the basic unit for data collection, with one probe associated with each execution plan node. This memory monitor probe design includes the following:

[0143] (1) Node identification information: used to uniquely identify the detection object, including query ID, plan node ID, node type (such as sorting, hash connection) and node name.

[0144] (2) Memory statistics: Responsible for recording dynamic memory usage data, including current memory consumption, peak memory consumption and memory usage limits of the node.

[0145] (3) Time statistics: Record the start and end times of the node, which are used to calculate the time consumption and associated time series.

[0146] (4) Context information: It is associated with the "memory context" at the kernel level, so that it can accurately locate which module or execution stage the memory was consumed.

[0147] Optionally, the Plan Node Monitor can be a management unit responsible for coordinating all probes throughout the query process. The design of this Plan Node Monitor includes the following:

[0148] (1) Detection status control: includes a global detection switch and a flag indicating whether the sampling mode is enabled, allowing dynamic adjustment of detection intensity to balance performance overhead.

[0149] (2) Probe management: Maintain a probe array to manage all active detection probes in the current query, and set an upper limit to prevent excessive use of resources.

[0150] (3) Shared statistical storage: A shared memory hash table is used to store statistical results, which enables all database backend processes to write and read detection data efficiently and concurrently, ensuring the real-time performance and consistency of the data.

[0151] For example, memory detection probes are "sensors" attached to each execution node, responsible for collecting detailed operational data; while execution node detectors are the "central management system," responsible for managing all these sensors and providing an efficient data aggregation and storage center. The collaborative work of these two core components enables fine-grained, low-overhead memory detection capabilities for the SQL execution process.

[0152] Figure 3 This is a flowchart illustrating the initialization preparation process in an execution plan node management method provided in this application. Figure 3 As shown, the method includes:

[0153] After startup, the system performs query parsing and plan generation, traverses the execution plan tree, creates a detection probe for each plan node, executes the registered memory context callback function, initializes the statistical data structure, and completes the readiness check.

[0154] Optionally, the management system can traverse the execution plan tree generated by the query optimizer. Then, a dedicated memory probe is created for each execution plan node in the tree (e.g., sorting, hash join, etc.). Callback functions are then registered in the memory context corresponding to each of these nodes to trigger logging during memory allocation and deallocation. Finally, a shared data structure for storing statistics is initialized, preparing for real-time data acquisition.

[0155] Figure 4 This is a flowchart illustrating the execution-time detection and data collection method in the execution plan node management method provided in this application. Figure 4 As shown, the method includes:

[0156] (1) Pre-execution hook: After the query executor starts, the preprocessing program of the detection module is called first.

[0157] (2) Install probes: The system traverses the execution plan tree again and "installs" the detection probes created in the first stage onto specific nodes. This process installs specific detection hooks based on the node type (sorting, hashing, etc.) to ensure that the most relevant memory activities are captured.

[0158] (3) Normal execution and automatic detection: The query is executed according to the standard process. The key point is that since the previously registered hooks and callback functions are already in place, the memory consumption will be automatically recorded in the corresponding detection probes, and the whole process is transparent to the execution engine.

[0159] (4) Post-execution statistics and cleanup: After the query is completed, the detection module will perform post-execution processing, summarize the final statistical information (such as peak memory), write it into the persistent statistics table, and finally clean up the detection resources of the query.

[0160] The above method achieves an "embedded central control" detection system. By completing the "wiring" (creating probes and registering hooks) before query execution, memory data can be automatically and in real time collected during query execution, and then uniformly summarized and saved after execution.

[0161] Optionally, the management system can also implement data acquisition and storage based on a two-level storage structure and an adaptive sampling strategy.

[0162] Optionally, the two-level data storage structure employs two core data tables to carry information at different granularities, which may include a core statistics table and a time-series table. For example, the core statistics table could record the complete lifecycle information of each execution plan node. It not only captures identification information such as the query identity document (ID) and node type, but more importantly, records key indicators such as current memory, peak memory, and memory limits, as well as detailed contextual data such as execution start and end times, and the number of memory allocations / releases.

[0163] Time series tables can be used for in-depth performance profiling. They periodically sample and record the memory usage changes of specific nodes during execution at higher frequencies, thus reconstructing a waveform of memory growth over time for precise analysis of memory consumption patterns.

[0164] Optionally, intelligent adaptive sampling mechanisms may include threshold filtering, frequency control, and dynamic decision-making. For example, threshold filtering might involve recording detailed data only for nodes whose memory consumption exceeds a preset minimum threshold, ignoring negligible memory allocations. Frequency control could sample at configurable time intervals to avoid generating excessive performance data. Dynamic decision-making could involve a dedicated sampling controller determining in real-time whether to record the current memory state, thereby significantly reducing unnecessary overhead.

[0165] Optionally, historical data management can utilize automated archiving and cleanup tasks to move older data from the core statistics table to the historical table. This ensures both the performance of real-time queries and the construction of a complete long-term historical data warehouse, laying the data foundation for time-series-based trend analysis, capacity planning, and performance prediction.

[0166] Using the above methods, based on core table snapshots, time series table process recording, sampling strategy overhead optimization, and archiving mechanism lifecycle management, a comprehensive data support system is constructed, from real-time fine-grained detection to long-term macro analysis.

[0167] Optionally, the management system can also present complex memory statistics to users in the form of easily queryable SQL tables by creating a series of virtual views. These views are mainly divided into two categories:

[0168] (1) Real-time monitoring view: For example, it can be a "real-time dashboard" that can display the query being executed and the memory consumption of each node, including current memory, peak memory and running time, so that the administrator can discover performance bottlenecks in time.

[0169] (2) Historical Analysis View: By linking completed queries, it provides a more comprehensive analysis dimension. It can display the absolute memory usage, calculate memory utilization (the percentage of peak memory to the limit), and can be linked with the system view to directly correspond to specific SQL statements, which facilitates root cause analysis.

[0170] Optionally, the management system can also automatically diagnose and provide solutions through an intelligent optimization suggestion engine. Based on preset rules and historical patterns, it automatically analyzes memory statistics and generates actionable optimization suggestions. For example, the management system can scan memory statistics through the engine to identify abnormal patterns. For instance, an abnormal pattern might be that the memory consumption of a sorting node exceeds its working configuration parameters, or that a hash connection node is allocated a large amount of memory but its actual utilization is very low.

[0171] Optionally, the management system can provide specific remedial suggestions through the engine for each diagnosed problem. For example, for sorting memory overflow, it may suggest increasing the size of the working configuration parameter or creating an index for the sorting field; for inefficient hash joins, it may suggest adjusting the hash join parameters or reviewing the join conditions. The engine can also add estimated improvement effects, such as an expected 50% performance increase or an expected 30% reduction in memory usage.

[0172] The above methods achieve a closed loop from "data" to "insight" to "action." Dynamic views make memory consumption visible and understandable. The optimization suggestion engine further automates problem diagnosis and directly provides remedial solutions, significantly improving the efficiency of database performance tuning.

[0173] Optionally, the management system can also adjust the intensity and scope of the detection behavior according to the actual business scenario and performance requirements by setting configuration parameters. For example, the following parameters may be included:

[0174] (1) Master switch: Allows users to enable or disable the entire memory detection function with one click, which is convenient for maintenance or troubleshooting.

[0175] (2) Sampling and frequency control: Users can set the sampling time interval, which determines the frequency of data acquisition; at the same time, a minimum memory threshold can be set, and only nodes whose memory consumption exceeds this threshold will be detected in detail, effectively filtering out a large number of fragmented and irrelevant memory allocations.

[0176] (3) Resource protection mechanism: By setting the maximum number of detection probes for each query, abnormally complex queries are prevented from consuming too many detection resources, thus ensuring system stability.

[0177] (4) Data lifecycle management: Set the number of days for automatic data retention. The system will automatically clean up or archive historical data accordingly to avoid the data from expanding indefinitely.

[0178] (5) Smart function switch: Users can choose whether to enable the automatic optimization suggestion generation function and obtain intelligent diagnostic results as needed.

[0179] By using the above methods, configuration parameters allow database administrators (DBAs) to fine-tune the granularity, overhead, and intelligent functions of detection based on the specific load and performance goals of the production environment, ensuring that it can be implemented in a production-friendly and resource-controlled manner.

[0180] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0181] Figure 5This application provides a schematic diagram of the structure of an execution plan node management device, as shown below. Figure 5 As shown, the execution plan node management device 500 provided in this embodiment includes: a creation module 501, a registration module 502, and a generation module 503. Wherein,

[0182] Create module 501 to traverse the database's execution plan tree and create a probe for each execution plan node in the tree;

[0183] The registration module 502 is used to register the probe of each execution plan node to the memory context corresponding to each execution plan node, and each memory context is associated with the memory allocation event of each execution plan node;

[0184] The generation module 503 is used to record the memory allocation data and memory release data of the memory context in real time through the probe, and generate the memory consumption record of each execution plan node.

[0185] Optionally, the registration module 502 is further configured to include at least one of the following information in each probe: node identification information, memory statistics information, time statistics information, and context information; wherein the node identification information is used to identify the object detected by the probe, the memory statistics information is used to record dynamic memory usage data, the time statistics information is used to record the start and end execution times of the object, and the context information is used to locate the module and stage of memory usage; and / or,

[0186] This execution plan tree is obtained by parsing an SQL statement. Each node in the execution plan represents a database operation operator. Each execution plan node includes one of the following: scan node, join node, aggregation node, sort node; and / or,

[0187] The memory context is a tree structure, arranged from top to bottom. The first level is the root context of the entire database process, the second level is the query context allocated for each query, the third level is the executor state context, the fourth level is the execution plan node context, and the fifth level is the private context of each execution plan node.

[0188] Optionally, the generation module 503 is also used to trigger data acquisition based on the memory allocation event of the memory context, and record the following information of the memory allocation event into the memory consumption record: memory allocation size, memory allocation timestamp, memory release size, memory release timestamp, and memory context identifier.

[0189] Optionally, the generation module 503 is further configured to divide the memory consumption record into a core statistics table and a time series table according to the time dimension. The core statistics table stores snapshot data of the node's lifecycle, and the time series table stores waveform data of memory changes. The method also includes at least one of the following:

[0190] Predict future memory peak values ​​based on the periodic patterns in the memory waveform data;

[0191] Based on the mutation point detection of this memory waveform data, the risk of memory overflow is predicted.

[0192] The long-term memory growth trend can be predicted based on trend line fitting of the memory waveform data.

[0193] Optionally, the generation module 503 is also used to display a dynamic performance view based on the memory consumption record; the dynamic performance view includes a real-time detection view and a historical analysis view, the real-time detection view is used to display the currently executing query and the memory consumption of each node, and the historical analysis view is used to display the intelligent diagnostic results obtained by intelligently diagnosing the database based on historical data.

[0194] Optionally, the generation module 503 is also used to display the parameter configuration interface;

[0195] Based on this parameter configuration interface, users can receive personalized settings.

[0196] The parameter configuration interface should include at least the following:

[0197] The master switch setting control allows users to enable or disable the entire memory detection function globally with a single click.

[0198] The sampling and frequency control settings are used to set the sampling time interval and the minimum memory threshold.

[0199] Resource protection mechanism settings control, used to set the maximum number of detection probes per query;

[0200] The data lifecycle settings control is used to set the number of days data is automatically retained;

[0201] The intelligent function switch setting control allows users to choose whether to enable the automatic optimization suggestion generation function and whether to obtain intelligent diagnostic results.

[0202] Optionally, the generation module 503 is further configured to dynamically adjust the data acquisition frequency based on the memory allocation size of the memory consumption record; wherein, when the memory allocation size exceeds a preset threshold, the sampling frequency is increased, and when the allocation size is lower than the preset threshold, the sampling frequency is decreased.

[0203] The execution plan node management device provided in this embodiment can execute the methods provided in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0204] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 6 As shown, the electronic device 600 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 600 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0205] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0206] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0207] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0208] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0209] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0210] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0211] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0212] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0213] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0214] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0215] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0216] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0217] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0218] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0219] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0220] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for managing execution plan nodes, characterized in that, The method includes: Traverse the execution plan tree of the database and create a probe for each execution plan node in the execution plan tree; The probe of each execution plan node is registered to the memory context corresponding to each execution plan node, and each memory context is associated with the memory allocation event of each execution plan node; The probe records the memory allocation and release data of the memory context in real time, generating memory consumption records for each execution plan node.

2. The method according to claim 1, characterized in that, Each probe includes at least one of the following information: node identification information, memory statistics information, time statistics information, and context information; wherein, the node identification information is used to identify the object detected by the probe, the memory statistics information is used to record dynamic memory usage data, the time statistics information is used to record the start and end execution times of the object, and the context information is used to locate the module and stage of memory usage; and / or, The execution plan tree is obtained by parsing an SQL statement. Each execution plan node is a database operation operator, and each execution plan node includes one of the following: scan node, join node, aggregation node, sort node; and / or, The memory context is a tree structure, arranged from top to bottom. The first layer is the root context of the entire database process, the second layer is the query context allocated to each query, the third layer is the executor state context, the fourth layer is the execution plan node context, and the fifth layer is the private context of each execution plan node.

3. The method according to claim 1 or 2, characterized in that, The step of recording memory allocation and release data of the memory context in real time through the probe, and generating memory consumption records for each execution plan node, includes: Data collection is triggered based on the memory allocation event of the memory context, and the following information of the memory allocation event is recorded in the memory consumption record: memory allocation size, memory allocation timestamp, memory release size, memory release timestamp, and memory context identifier.

4. The method according to claim 3, characterized in that, The memory consumption records are divided into a core statistics table and a time series table according to the time dimension. The core statistics table stores snapshot data of the node's lifecycle, and the time series table stores memory waveform data. The method further includes at least one of the following: Predict future memory peak values ​​based on the periodic patterns of the memory waveform data; Based on the mutation point detection of the aforementioned memory waveform data, the risk of memory overflow is predicted. The long-term memory growth trend is predicted based on trend line fitting of the memory waveform data.

5. The method according to claim 1 or 2, characterized in that, The method further includes: The dynamic performance view is displayed based on the memory consumption records. The dynamic performance view includes a real-time detection view and a historical analysis view. The real-time detection view is used to display the currently executing queries and the memory consumption of each node. The historical analysis view is used to display the intelligent diagnostic results obtained by intelligently diagnosing the database based on historical data.

6. The method according to claim 5, characterized in that, The method further includes: Display parameter configuration interface; The user's personalized settings are received based on the parameter configuration interface; The parameter configuration interface shall include at least the following: The master switch setting control allows users to enable or disable the entire memory detection function globally with a single click. The sampling and frequency control settings are used to set the sampling time interval and the minimum memory threshold. Resource protection mechanism settings control, used to set the maximum number of detection probes per query; The data lifecycle settings control is used to set the number of days data is automatically retained; The intelligent function switch setting control allows users to choose whether to enable the automatic optimization suggestion generation function and whether to obtain intelligent diagnostic results.

7. The method according to claim 1 or 2, characterized in that, The method further includes: The data collection frequency is dynamically adjusted based on the memory allocation size recorded in the memory consumption log; wherein, the sampling frequency is increased when the memory allocation size exceeds a preset threshold, and the sampling frequency is decreased when the allocation size is lower than the preset threshold.

8. An execution plan node management device, comprising: A module is created to traverse the execution plan tree of the database and create a probe for each execution plan node in the execution plan tree; The registration module is used to register the probe of each execution plan node to the memory context corresponding to each execution plan node, and each memory context is associated with the memory allocation event of each execution plan node; The generation module is used to record the memory allocation data and memory release data of the memory context in real time through the probe, and generate the memory consumption record of each execution plan node.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images