Method and device for evaluating performance risk of database query statement, and electronic device

Abstract

This invention discloses a method, apparatus, and electronic device for performance risk assessment of database query statements, relating to the field of database technology or other related fields. The method includes: converting the query statement to be assessed into a query semantic vector using a large language model; collecting operational status data synchronized between the database system and the execution interval based on the execution interval of the query statement; performing joint feature fusion on the query semantic vector and the operational status data using a feature fusion model to generate a joint feature vector, wherein the joint feature vector is used to characterize the performance impact of the query statement in the context of the database system; assessing the performance risk level caused by the query statement based on the joint feature vector, and outputting a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold. This invention solves the technical problem in related technologies where it is difficult to accurately assess the performance risks caused by database query statements, leading to a decrease in database service stability.

Description

Technical Field

[0001] This invention relates to the field of database technology, and more specifically, to a method, apparatus, and electronic device for performance risk assessment of database query statements. Background Technology

[0002] As businesses expand and database systems become more complex, the performance of SQL statements directly impacts the stability and responsiveness of these systems. Current mainstream database performance monitoring methods primarily rely on time-series analysis of historical performance metrics, employing statistical or machine learning models for trend prediction. While these methods can reflect dynamic changes in system resources, their input is limited to numerical performance metrics, completely ignoring the semantic structure and execution intent of the SQL statements themselves. This leads to significant prediction biases when dealing with complex queries, nested subqueries, multi-table JOINs, or missing indexes, as they fail to accurately identify the root causes of performance degradation.

[0003] Meanwhile, the analysis results of some systems are independent of the actual operating environment and cannot be linked with real-time system load, lock contention, I / O pressure, and other operational statuses, resulting in a disconnect between semantic and performance evaluation. Furthermore, existing operation and maintenance platforms mostly use fixed threshold alarm mechanisms, triggering alerts only after indicators exceed limits. They lack the ability to proactively identify potential risks caused by semantic changes and cannot integrate multi-source information such as operation and maintenance logs, configuration changes, and index usage status, leading to a single dimension of risk identification, high false alarm rates, and delayed response. More importantly, existing solutions are all static models, unable to adaptively optimize based on actual operational feedback data after deployment, making them ill-suited for the high-concurrency, dynamically changing modern database operation and maintenance environment.

[0004] The aforementioned technologies cannot detect performance risks in advance in complex query or resource contention scenarios. At the same time, due to the lack of joint modeling and self-learning capabilities for multimodal information, they are also unable to support intelligent and automated database operation and maintenance decisions, which seriously restricts the stability and operation and maintenance efficiency of database systems in critical business scenarios.

[0005] There is currently no effective solution to the above problems. Summary of the Invention

[0006] This invention provides a method, apparatus, and electronic device for assessing the performance risks of database query statements, thereby addressing the technical problem in related technologies where it is difficult to accurately assess the performance risks caused by database query statements, leading to a decline in the stability of database services.

[0007] According to one aspect of the present invention, a method for performance risk assessment of a database query statement is provided, comprising: converting the query statement to be assessed into a query semantic vector through a large language model, wherein the query semantic vector is used to characterize the semantic structure and execution intent of the query statement; collecting operational status data of the database system synchronized with the execution interval based on the execution interval of the query statement; performing joint feature fusion on the query semantic vector and the operational status data through a feature fusion model to generate a joint feature vector, wherein the joint feature vector is used to characterize the performance impact of the query statement in the context of the database system; assessing the performance risk level caused by the query statement based on the joint feature vector, and outputting a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

[0008] Furthermore, the step of transforming the query statement to be evaluated into a query semantic vector using a large language model includes: obtaining the original text of the query statement to be evaluated; parsing the grammatical structure of the query statement based on the original text, and extracting at least one grammatical structure feature from selection, connection, filtering, grouping, and subquery nesting levels; concatenating the grammatical structure feature with the original text of the query statement to obtain an enhanced grammatical structure feature; inputting the enhanced grammatical structure feature into the large language model, which analyzes the execution intent of the query statement and outputs the query semantic vector.

[0009] Further, the step of collecting runtime status data synchronized between the database system and the execution interval based on the execution interval of the query statement includes: extracting the start and end timestamps of the query statement from the execution log of the database system to obtain the execution interval; determining a performance collection window based on the execution interval, and continuously collecting system performance indicators at specified collection intervals within the performance collection window to obtain the runtime status data, wherein the system performance indicators include at least one of the following: CPU utilization, memory usage, disk I / O throughput, lock wait time, or SQL execution time.

[0010] Furthermore, the step of generating a joint feature vector by performing joint feature fusion on the query semantic vector and the running status data through a feature fusion model includes: performing dimensional standardization on the query semantic vector in the feature fusion model; performing sliding window aggregation on the running status data to obtain a running status vector that is temporally aligned with the query semantic vector; and concatenating the dimensionally standardized query semantic vector and the running status vector along the feature dimension to obtain the joint feature vector.

[0011] Further, the step of evaluating the performance risk level caused by the query statement based on the joint feature vector includes: determining the semantic category to which the query semantic vector belongs, and obtaining the historical cluster center vector of the semantic category; calculating the cosine distance between the joint feature vector and the historical cluster center vector to obtain the semantic dissimilarity; comparing the semantic dissimilarity with a semantic baseline threshold, and determining the performance risk level based on the comparison result, wherein the semantic baseline threshold is dynamically updated based on historical semantic data.

[0012] Furthermore, the step of outputting a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold includes: matching the semantic category to which the query semantic vector belongs in a preset optimization template library to obtain an optimization suggestion set, wherein the optimization suggestion set includes at least one of: index recommendation, join order adjustment, and subquery rewriting; encapsulating the optimization suggestion set and the performance risk level into a structured warning signal and pushing it to the operation and maintenance terminal.

[0013] Furthermore, after outputting a warning signal to the operation and maintenance terminal, the method further includes: after the query statement is actually executed, collecting the current performance indicators of the database system to obtain execution feedback data; calculating the error between the execution feedback data and the joint feature vector to obtain evaluation error data; determining the corresponding model sub-modules in the large language model and the feature fusion model based on the semantic category of the query statement; adjusting the parameters of the model sub-modules based on the evaluation error data to obtain the updated large language model and the feature fusion model.

[0014] According to another aspect of the present invention, a performance risk assessment device for database query statements is also provided, comprising: a conversion unit, configured to convert the query statement to be assessed into a query semantic vector through a large language model, wherein the query semantic vector is used to characterize the semantic structure and execution intent of the query statement; a collection unit, configured to collect operational status data of the database system synchronized with the execution interval based on the execution interval of the query statement; a fusion unit, configured to perform joint feature fusion on the query semantic vector and the operational status data through a feature fusion model to generate a joint feature vector, wherein the joint feature vector is used to characterize the performance impact of the query statement in the context of the database system; and an assessment unit, configured to assess the performance risk level caused by the query statement based on the joint feature vector, and output a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

[0015] Further, the transformation unit includes: an acquisition module for acquiring the original text of the query statement to be evaluated; a parsing module for parsing the grammatical structure of the query statement based on the original text, and extracting at least one grammatical structure feature from selection, connection, filtering, grouping, and subquery nesting levels; a concatenation module for concatenating the grammatical structure features with the original text of the query statement to obtain enhanced grammatical structure features; and an input module for inputting the enhanced grammatical structure features into the large language model, whereby the large language model analyzes the execution intent of the query statement and outputs the query semantic vector.

[0016] Further, the acquisition unit includes: an extraction module, used to extract the start timestamp and end timestamp of the query statement from the execution log of the database system to obtain the execution interval; and a first acquisition module, used to determine a performance acquisition window based on the execution interval, and continuously acquire system performance indicators within the performance acquisition window according to a specified acquisition interval to obtain the running status data, wherein the system performance indicators include at least one of the following: CPU utilization, memory usage, disk I / O throughput, lock wait time, or SQL execution time.

[0017] Furthermore, the fusion unit includes: a first processing module, used to perform dimensional standardization processing on the query semantic vector in the feature fusion model; a second processing module, used to perform sliding window aggregation processing on the running state data to obtain a running state vector that is temporally aligned with the query semantic vector; and a concatenation module, used to concatenate the dimensionally standardized query semantic vector and the running state vector along the feature dimension to obtain the joint feature vector.

[0018] Further, the evaluation unit includes: a determination module, used to determine the semantic category to which the query semantic vector belongs, and obtain the historical cluster center vector of the semantic category; a first calculation module, used to calculate the cosine distance between the joint feature vector and the historical cluster center vector to obtain the semantic dissimilarity; and a comparison module, used to compare the semantic dissimilarity with a semantic baseline threshold, and determine the performance risk level based on the comparison result, wherein the semantic baseline threshold is dynamically updated based on historical semantic data.

[0019] Furthermore, the evaluation unit also includes: a matching module, used to perform matching in a preset optimization template library according to the semantic category to which the query semantic vector belongs, to obtain an optimization suggestion set, wherein the optimization suggestion set includes at least one of: index recommendation, join order adjustment, and subquery rewriting; and a push module, used to encapsulate the optimization suggestion set and the performance risk level into a structured warning signal and push it to the operation and maintenance terminal.

[0020] Furthermore, the performance risk assessment device for the database query statement further includes: a second acquisition module, used to acquire the current performance indicators of the database system and obtain execution feedback data after the query statement is actually executed, after outputting a warning signal to the operation and maintenance terminal; a second calculation module, used to perform error calculation on the execution feedback data and the joint feature vector to obtain evaluation error data; and an adjustment module, used to determine the corresponding model sub-modules in the large language model and the feature fusion model based on the semantic category of the query statement, and to adjust the parameters of the model sub-modules based on the evaluation error data to obtain the updated large language model and the feature fusion model.

[0021] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the database query statement described in any one of the above-described methods for performance risk assessment.

[0022] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the performance risk assessment method for database query statements described in any of the above embodiments.

[0023] According to another aspect of the present invention, a computer program product is also provided, including computer instructions, wherein when the computer instructions are executed by a processor, they implement the steps of the performance risk assessment method for database query statements described in any of the above embodiments.

[0024] This invention proposes a method for performance risk assessment of database query statements. First, the query statement to be assessed is transformed into a query semantic vector using a large language model. The query semantic vector represents the semantic structure and execution intent of the query statement. Then, based on the execution interval of the query statement, the running status data of the database system and the execution interval are collected synchronously. Next, a feature fusion model is used to perform joint feature fusion on the query semantic vector and the running status data to generate a joint feature vector. The joint feature vector represents the performance impact of the query statement in the context of the database system. Finally, the performance risk level caused by the query statement is assessed based on the joint feature vector, and a warning signal is output to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

[0025] This invention employs a deep fusion approach combining a large language model and multimodal time-series data. The large language model transforms the query statement to be evaluated into a query semantic vector representing its semantic structure and execution intent. Simultaneously, database system operating status data is collected based on the actual execution interval of the query statement, achieving precise temporal alignment between semantic features and the dynamic operating environment. Subsequently, a feature fusion model performs deep joint modeling of the two in a unified representation space, generating a joint feature vector that comprehensively reflects the potential performance impact of the query statement in the current system context. Finally, the performance risk level caused by the query statement is quantitatively assessed based on this joint feature vector, and an early warning signal is automatically triggered and pushed to the operation and maintenance terminal when the risk exceeds a preset threshold. This overcomes the limitations of traditional methods that rely solely on static indicators or isolated execution time to assess performance risk, achieving intelligent perception and risk prediction of the dynamic coupling relationship between the semantic intent of SQL statements and the system operating status. This improves the foresight and accuracy of database operation and maintenance, effectively preventing system performance fluctuations or service interruptions caused by high-risk queries. Ultimately, it solves the technical problem in related technologies where it is difficult to accurately assess the performance risks caused by database query statements, leading to a decline in database service stability. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0027] Figure 1 This is a flowchart of an optional database query statement performance risk assessment method according to an embodiment of the present invention;

[0028] Figure 2 This is a flowchart of an optional database SQL performance prediction method based on multimodal feature fusion and LLM model according to an embodiment of the present invention;

[0029] Figure 3 This is a structural diagram of an optional database SQL performance prediction method based on multimodal feature fusion and LLM model according to an embodiment of the present invention;

[0030] Figure 4 This is a schematic diagram of an optional semantic performance sample dataset structure according to an embodiment of the present invention;

[0031] Figure 5 This is a schematic diagram of an optional database query statement performance risk assessment device according to an embodiment of the present invention;

[0032] Figure 6 This is a structural block diagram of an electronic device for performance risk assessment of executing database query statements according to an embodiment of the present invention. Detailed Implementation

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

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

[0035] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0036] SQL, Structured Query Language, refers to a standardized query language used to manage relational databases. It is commonly used to perform data query, insertion, update, and deletion operations. In this invention, it specifically refers to SELECT-type query statements used to access databases, whose syntax includes keywords such as SELECT, JOIN, WHERE, and GROUP BY.

[0037] I / O, or Input / Output, refers to the data reading and writing process between a database system and a storage device (such as a disk or SSD). In this invention, "disk I / O throughput" refers to the amount of data read and written per unit time, which is a key performance indicator for evaluating database I / O pressure.

[0038] LLM, or Large Language Model, refers to a natural language processing model based on deep neural networks and trained on large-scale text corpora, possessing semantic understanding, context modeling, and vector representation capabilities. In this invention, it is used to transform the text structure of SQL statements into high-dimensional semantic vectors to capture their execution intent and semantic complexity.

[0039] The following embodiments of the present invention can be applied to various systems / applications / devices that require intelligent prediction of SQL statement performance risks and proactive intervention in database operation and maintenance. They enable pre-emptive warning and self-optimization closed-loop control of SQL performance based on semantic understanding and multimodal operational status fusion. The present invention uses a large language model to semantically vectorize SQL query statements, then synchronously collects system performance time-series data such as CPU, memory, I / O, and lock wait within the execution interval. A joint feature vector is constructed by concatenating feature dimensions, and combined with semantic clustering and dynamic thresholds to determine the risk level. This allows for more accurate identification of high-risk SQL statements before business deployment, automatic generation of optimization suggestions, and continuous model iteration, achieving a transformation from passive monitoring to proactive prevention in intelligent database operation and maintenance.

[0040] This invention uses semantic vectorization to replace traditional grammatical feature engineering. It breaks the spatiotemporal separation between semantics and performance by aligning runtime states, replaces fixed threshold alarms with a risk judgment mechanism driven by joint feature concatenation and clustering, and achieves continuous accumulation of operational knowledge through self-updating of semantic category-aware model sub-modules. It fundamentally solves the core pain points of existing technologies such as "only looking at indicators, not understanding semantics", "post-event alarms, unable to intervene", and "model rigidity, unable to evolve".

[0041] The present invention will now be described in detail with reference to various embodiments.

[0042] Example 1

[0043] According to an embodiment of the present invention, a method for performance risk assessment of database query statements is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0044] The implementing entity of this invention can be a database intelligent operation and maintenance system, or integrated into various operation and maintenance environments that require high database availability, such as enterprise-level database management platforms, domestic cloud database centers, pre-deployment performance review platforms, and financial / telecommunications core system monitoring platforms. It combines large language model semantic understanding, multimodal temporal feature fusion and closed-loop self-learning optimization technologies, as well as data processing technologies such as SQL semantic vectorization, execution interval alignment, cross-modal attention modeling, and dynamic risk index calculation. This enables proactive identification and automated intervention of potential performance risks in SQL query statements. It is particularly suitable for performance drops, frequent slow queries, service jitter, and even downtime caused by SQL semantic complexity and system resource competition before business deployment. Specifically, it constructs a "semantic-performance" joint representation and hierarchical early warning closed-loop mechanism. This includes: (1) using a large language model to convert SQL statements into semantic vectors and extract their deep execution intent; (2) locking the execution interval based on the timestamp of the SQL execution log and synchronously collecting system running status data such as CPU, memory, I / O, and lock wait; (3) standardizing and aligning the semantic vector and the running status vector in dimensions, and splicing them together to generate a joint feature vector; (4) introducing semantic clustering centers and dynamic thresholds to calculate a comprehensive risk index; (5) automatically matching optimization strategies such as index recommendation, JOIN order adjustment, or subquery rewriting based on the risk level; (6) collecting real feedback after the actual execution of SQL, triggering incremental updates of model sub-modules according to semantic categories, and achieving self-evolution—in order to achieve the goal of upgrading the database intelligent operation and maintenance paradigm from "post-event alarm" to "pre-event prediction, automatic intervention, and continuous learning".

[0045] The embodiments of the present invention will now be described in detail with reference to the specific implementation steps.

[0046] Figure 1 This is a flowchart of an optional database query statement performance risk assessment method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0047] Step S101: The query statement to be evaluated is transformed into a query semantic vector through a large language model. The query semantic vector is used to represent the semantic structure and execution intent of the query statement.

[0048] In this embodiment, the query statement to be evaluated is first semantically parsed using a large language model. The structured text content of the query statement is transformed into a set of numerical vector representations. These vectors serve as the query semantic vectors, with each dimension corresponding to the abstract encoding of the lexical structure, syntactic relations, and execution intent within the language model. This achieves a digital representation of the semantic features of the query statement. This process does not rely on preset rules or manual feature extraction. Instead, the large language model, based on its language understanding capabilities acquired during training, directly derives the semantic connotation from the natural language form of the query statement and solidifies it in the form of vectors in a high-dimensional space. This vector is then used to establish semantic associations with database performance data.

[0049] Furthermore, the steps of transforming the query statement to be evaluated into a query semantic vector using a large language model include: obtaining the original text of the query statement to be evaluated; parsing the grammatical structure of the query statement based on the original text, and extracting at least one grammatical structure feature from selection, connection, filtering, grouping, and subquery nesting levels; concatenating the grammatical structure features with the original text of the query statement to obtain enhanced grammatical structure features; and inputting the enhanced grammatical structure features into the large language model, which analyzes the execution intent of the query statement and outputs the query semantic vector.

[0050] In this embodiment, the original text of the query statement to be evaluated is obtained and its grammatical structure is parsed. At least one structural feature from selection, connection, filtering, grouping, and subquery nesting hierarchy is extracted. This structural feature is then concatenated with the original text to form an enhanced grammatical structure feature, which is then input into the large language model. This allows the model to generate query semantic vectors that not only rely on the surface semantics of the statement but also combine its deep grammatical structure information, thereby more accurately identifying the execution intent of complex query statements and significantly improving the discriminative and representational capabilities of semantic vectors in the semantic space. Consequently, the joint feature vector generated by subsequent fusion with database operation status data more realistically reflects the performance impact of the query statement in the actual operating environment, ultimately achieving accurate assessment of performance risk levels and triggering timely warnings when risks exceed limits. This effectively overcomes the problems of ambiguous intent recognition and insufficient semantic discrimination caused by relying solely on the original text input, improving the accuracy and reliability of performance risk identification in database operation and maintenance.

[0051] Step S102: Based on the execution interval of the query statement, collect the running status data of the database system synchronized with the execution interval.

[0052] In this embodiment, the system's operational status data is first collected synchronously based on the execution interval of the query statement, ensuring that the acquired system behavior data completely corresponds to the lifecycle of the specific query statement. This process requires that the time range of the collection action be strictly limited to the period from the start to the end of the query statement's execution. The collected data covers the dynamic changes of internal database resources within this interval, including but not limited to system-level performance indicators such as CPU utilization, memory usage, I / O throughput, and lock wait time. Through time alignment, it is ensured that each piece of collected operational status data can be clearly attributed to the execution process of a specific query statement, thereby establishing a direct correlation between the query behavior and the system response it triggers, providing an accurate and time-consistent raw data foundation for subsequent analysis.

[0053] Furthermore, the step of collecting runtime status data synchronized between the database system and the execution interval based on the execution interval of the query statement includes: extracting the start and end timestamps of the query statement from the execution log of the database system to obtain the execution interval; determining a performance collection window based on the execution interval, and continuously collecting system performance indicators within the performance collection window at specified collection intervals to obtain runtime status data, wherein the system performance indicators include at least one of the following: CPU utilization, memory usage, disk I / O throughput, lock wait time, or SQL execution time.

[0054] In this embodiment, the start and end timestamps of the query statement to be evaluated are accurately extracted from the execution log of the database system to determine its actual execution interval. Based on this interval, a performance collection window is dynamically defined to ensure that the collection time range of system performance indicators is completely synchronized with the actual execution process of the query statement. Within this window, key operational status data such as CPU utilization, memory usage, disk I / O throughput, lock wait time, or SQL execution time are continuously acquired at preset collection intervals. This ensures that the collected system behavior data truly reflects the resource consumption and concurrency impact of the query statement in a specific context. Subsequently, the query semantic vector generated by the large language model is fused with the high-precision synchronized operational status data to generate a joint feature vector that accurately represents the coupling relationship between semantic intent and system response. This enables a refined assessment of performance risk levels and timely triggers maintenance warnings when the risk exceeds a threshold. This effectively solves the problem of inaccurate assessment caused by the mismatch between the collection window and the execution period in traditional methods, significantly improving the accuracy of performance risk identification and the timeliness of maintenance response.

[0055] Step S103: Through the feature fusion model, the query semantic vector and the running status data are jointly fused to generate a joint feature vector, which is used to characterize the performance impact of the query statement in the context of the database system.

[0056] In this embodiment, a feature fusion model is first used to perform joint feature fusion on the query semantic vector and runtime status data. The query semantic vector is derived from the semantic parsing of the SQL statement and transformed by a large language model, while the runtime status data represents the real-time performance indicators of the database system during query execution. The two are represented collaboratively across modalities through the feature fusion model. This process does not rely on isolated analysis of a single dimension, but rather maps the semantic-level query intent and the system-level resource carrying capacity to a unified feature space, thereby directly generating a joint feature vector that comprehensively reflects the overall performance impact of the query statement in the current database runtime context. The generation of this vector does not involve the separate evaluation or weighted calculation of specific indicators, but is automatically constructed by the feature fusion model based on the inherent correlation between the semantic vector and the runtime status data, directly representing the dynamic coupling relationship between query behavior and system resource status.

[0057] Furthermore, the steps of performing joint feature fusion on the query semantic vector and the running status data through the feature fusion model to generate a joint feature vector include: performing dimensional standardization on the query semantic vector in the feature fusion model; performing sliding window aggregation on the running status data to obtain a running status vector that is temporally aligned with the query semantic vector; and concatenating the dimensionally standardized query semantic vector and the running status vector along the feature dimensions to obtain the joint feature vector.

[0058] In this embodiment, the query statement to be evaluated is transformed into a query semantic vector representing its semantic structure and execution intent using a large language model. Simultaneously, the runtime status data of the database system within the execution interval of the query statement is collected. Then, the query semantic vector is dimensionally standardized in the feature fusion model to eliminate inconsistencies between its feature scale and that of the runtime status data. At the same time, the runtime status data is processed using a sliding window aggregation method to extract runtime status vectors that match the temporal granularity of the query semantic vector, achieving precise alignment between the two in the time dimension. The dimensionally standardized query semantic vector and the aligned runtime status vector are then concatenated and fused along the feature dimension to form a joint feature vector with a unified structure and synergistic representation of semantic and contextual information. This accurately characterizes the performance impact of the query statement in the real database operating environment. Finally, the performance risk level caused by the query is assessed based on this joint feature vector, and an early warning is triggered when the risk exceeds the limit. This effectively solves the problem of inaccurate feature fusion caused by inconsistencies in the dimensions and temporal synchronization between the semantic vector and the runtime status data, significantly improving the accuracy and reliability of performance risk assessment.

[0059] Step S104: Evaluate the performance risk level caused by the query statement based on the joint feature vector, and output a warning signal to the operation and maintenance terminal when the risk level exceeds the preset risk threshold.

[0060] In this embodiment, assessing the performance risk level caused by a query statement based on a joint feature vector means taking a joint feature vector generated by fusing multiple sources of information such as performance time series, SQL semantics, operation and maintenance logs, and configuration changes as input, and using preset calculation logic to quantitatively assess the system performance risks that the query statement may cause, and obtaining a risk value with a level meaning; when the risk value exceeds a preset threshold, the system determines that the query statement has a performance risk that exceeds the acceptable range, and automatically triggers the output of a warning signal to the operation and maintenance terminal to prompt the operation and maintenance personnel to pay attention and intervene. The whole process does not rely on manual judgment, but is driven by the system directly based on the comparison result of the joint feature vector and the threshold.

[0061] Furthermore, the steps for evaluating the performance risk level caused by a query statement based on the joint feature vector include: determining the semantic category to which the query semantic vector belongs and obtaining the historical cluster center vector of the semantic category; calculating the cosine distance between the joint feature vector and the historical cluster center vector to obtain the semantic dissimilarity; comparing the semantic dissimilarity with the semantic baseline threshold and determining the performance risk level based on the comparison result, wherein the semantic baseline threshold is dynamically updated based on historical semantic data.

[0062] In this embodiment, the query statement to be evaluated is transformed into a query semantic vector representing its semantic structure and execution intent through a large language model. Combined with database operation status data collected synchronously during the query execution interval, a joint feature vector that comprehensively reflects the semantic intent and the influence of system context is generated through a feature fusion model. Furthermore, by identifying the historical semantic category to which the query semantic vector belongs, the historical cluster center vector corresponding to the category is retrieved, and the cosine distance between the joint feature vector and the cluster center is calculated to quantify the degree of deviation between the current query semantics and historical typical patterns, forming a semantic difference degree. This difference degree is then compared with a dynamically updated semantic baseline threshold, thereby accurately determining the performance risk level based on the deviation strength of the semantic distribution. This effectively overcomes the shortcomings of relying solely on the joint feature vector for static evaluation while ignoring the evolution and abnormal deviation of semantic patterns. It achieves sensitive identification of newly emerging high-risk semantic patterns and differentiated early warning of known high-risk patterns, significantly improving the accuracy and dynamic adaptability of risk assessment.

[0063] Furthermore, the step of outputting a warning signal to the operation and maintenance terminal when the risk level exceeds the preset risk threshold includes: matching the query semantic vector in a preset optimization template library to obtain an optimization suggestion set, wherein the optimization suggestion set includes at least one of: index recommendation, join order adjustment, and subquery rewriting; encapsulating the optimization suggestion set and the performance risk level into a structured warning signal and pushing it to the operation and maintenance terminal.

[0064] In this embodiment, the query statement to be evaluated is transformed into a query semantic vector representing its semantic structure and execution intent through a large language model. Combined with database operation status data collected synchronously during the query execution period, a joint feature vector reflecting the interaction between semantic intent and system context is generated by a feature fusion model, thereby accurately assessing the performance risk level. When the risk level exceeds a preset threshold, a preset optimization template library is automatically matched according to the semantic category to which the query semantic vector belongs. At least one actionable optimization suggestion is extracted from the following options: index recommendation, join order adjustment, or subquery rewriting, corresponding to the semantic category. This forms a structured set of optimization suggestions, which, together with the performance risk level, is packaged into a unified format warning signal and pushed to the operation and maintenance terminal. This allows operation and maintenance personnel to not only know the risk level but also directly obtain targeted optimization guidance, thereby effectively solving the problems of vague warning information and lack of actionable guidance that lead to delayed response and inefficient optimization. This achieves a closed-loop linkage between risk warning and intelligent repair suggestions, significantly improving the response speed and handling accuracy of database operation and maintenance.

[0065] Furthermore, after outputting the warning signal to the operation and maintenance terminal, the method also includes: after the query statement is actually executed, collecting the current performance indicators of the database system to obtain execution feedback data; calculating the error between the execution feedback data and the joint feature vector to obtain evaluation error data; determining the corresponding model sub-modules in the large language model and feature fusion model based on the semantic category of the query statement; adjusting the parameters of the model sub-modules based on the evaluation error data to obtain the updated large language model and feature fusion model.

[0066] In this embodiment, after the query statement is executed, the current performance indicators of the database system are collected to generate execution feedback data. This data is then compared with the previously generated joint feature vector to calculate the error, obtaining evaluation error data that reflects the evaluation prediction deviation. Based on the semantic category of the query statement, the corresponding functional sub-modules in the large language model and feature fusion model are accurately located. Based on the evaluation error data, the parameters of the located sub-modules are fine-tuned to achieve local adaptive optimization of the model in the semantic category dimension. This continuously improves the semantic understanding accuracy and performance risk assessment accuracy of similar query statements without destroying the overall model structure. It effectively overcomes the problem of evaluation deviation accumulation caused by the lack of feedback loop mechanism in the original method, and achieves the effect of online self-evolution of the model and continuous iteration and enhancement of risk identification capability with actual running data.

[0067] Through the above steps S101 to S104, the query statement to be evaluated can first be transformed into a query semantic vector through a large language model. The query semantic vector is used to represent the semantic structure and execution intent of the query statement. Then, based on the execution interval of the query statement, the running status data synchronized between the database system and the execution interval is collected. Then, through a feature fusion model, the query semantic vector and the running status data are jointly fused to generate a joint feature vector. The joint feature vector is used to represent the performance impact of the query statement in the context of the database system. Finally, the performance risk level caused by the query statement is evaluated based on the joint feature vector, and a warning signal is output to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

[0068] By applying the technical solution of this embodiment, the SQL query statement to be evaluated is transformed into a query semantic vector representing its semantic structure and execution intent through a large language model. Simultaneously, the database system's operational status data within the actual execution interval of the query statement is collected, achieving dynamic coupling between semantic features and the operational environment. Then, a feature fusion model is used to deeply jointly model the two, generating a joint feature vector that comprehensively reflects the potential performance impact of the query statement in the current system context. Finally, based on this joint feature vector, the performance risk level caused by the query statement is quantitatively evaluated, and a warning signal is proactively pushed to the operation and maintenance terminal when the risk exceeds a preset threshold. This overcomes the limitations of traditional methods that rely solely on static rules or isolated indicators to assess performance risk, achieving accurate risk identification by organically integrating SQL semantic features with real-time operational status. It effectively solves the problem of inaccurate assessment caused by the inability to dynamically correlate semantic features with system status in existing technologies, thus improving the accuracy, timeliness, and interpretability of database performance risk warnings and ensuring the stable and efficient operation of the database.

[0069] In this embodiment of the invention, a deep fusion of a large language model and multimodal time-series data is employed. The large language model transforms the query statement to be evaluated into a query semantic vector representing its semantic structure and execution intent. Simultaneously, database system operating status data is collected based on the actual execution interval of the query statement, achieving precise temporal alignment between semantic features and the dynamic operating environment. Then, a feature fusion model performs deep joint modeling of the two in a unified representation space, generating a joint feature vector that comprehensively reflects the potential performance impact of the query statement in the current system context. Finally, the performance risk level caused by the query statement is quantitatively evaluated based on this joint feature vector, and an early warning signal is automatically triggered and pushed to the operation and maintenance terminal when the risk exceeds a preset threshold. This overcomes the limitations of traditional methods that rely solely on static indicators or isolated execution time to assess performance risk, achieving intelligent perception and risk prediction of the dynamic coupling relationship between the semantic intent of SQL statements and the system operating status. This improves the foresight and accuracy of database operation and maintenance, effectively preventing system performance fluctuations or service interruptions caused by high-risk queries, and thus solves the technical problem in related technologies where it is difficult to accurately assess the performance risks caused by database query statements, leading to a decline in database service stability.

[0070] The present invention will now be described with a more specific embodiment provided.

[0071] The technical challenges that need to be addressed in this implementation scenario include: ① Semantic and performance disconnect: Existing methods cannot establish a correlation between the semantic features of SQL statements and database performance metrics, resulting in low performance prediction accuracy in complex query scenarios. ② Insufficient multimodal feature fusion: Existing risk assessment methods typically rely solely on performance time-series data, lacking joint analysis of multi-source information such as SQL semantics, operation and maintenance logs, and configuration changes, leading to a single dimension of risk identification. ③ Poor model adaptability: Traditional prediction models, once deployed, are difficult to adjust parameters based on actual operational feedback, failing to achieve continuous optimization in the "prediction-feedback" loop. ④ Delayed risk warnings and false alarms: Alarm mechanisms based on fixed thresholds cannot identify potential risks caused by changes in SQL complexity and semantics in advance, resulting in insufficient timeliness and accuracy of warnings.

[0072] Figure 2 This is a flowchart of an optional database SQL performance prediction method based on multimodal feature fusion and LLM model according to an embodiment of the present invention, such as... Figure 2 As shown, it includes:

[0073] 1) The system initiates database performance monitoring and risk prediction tasks, which can be executed immediately or periodically. The immediate execution mode is used for rapid performance evaluation before critical business operations go live; the periodic mode collects database operating status periodically and continuously monitors performance trends.

[0074] 2) After the task starts, the Agent module deployed on the database host automatically collects performance indicators such as CPU utilization, memory usage, IOPS, SQL execution time, and lock wait time. The collected results are then cached, rate-limited, and formatted, and output as a standardized data stream.

[0075] 3) Once the performance data collection is complete, the system automatically starts the SQL semantic parsing process, performs structure recognition and complexity calculation on the collected SQL statements, transforms the SQL semantics into semantic vector representations through the LLM large language model, and establishes a correspondence with performance indicators to form a "semantic-performance" mapping sample set.

[0076] 4) Based on historical performance sequences and semantic features, the system adaptively selects a prediction model to fit and predict the trends of indicators such as CPU, IO, and memory, and smooths the results to output the resource usage trend of the database in the future time period.

[0077] 5) After the performance prediction results and semantic features are generated, the system automatically performs multimodal feature fusion, extracts features from multiple sources such as performance time series, SQL semantics, operation and maintenance logs, and configuration changes, learns the correlation between each modality through cross-modal attention mechanism, and generates a fused joint feature matrix.

[0078] 6) The system calculates a risk index based on the fusion features, and comprehensively evaluates SQL complexity, semantic differences, and performance deviation rate. When the risk index exceeds a preset threshold, the system automatically triggers a performance risk warning and generates different optimization suggestions based on the risk level: low risk suggests normal deployment, medium risk suggests SQL optimization or resource pre-allocation, and high risk suggests delaying deployment and triggering expert review.

[0079] 7) After the business goes live, the system continuously collects actual operation feedback data, compares the real results with the predicted results, and automatically corrects the model parameters through error calculation and gradient descent algorithm. This enables the system to achieve self-learning and optimization in the continuous "prediction-feedback-retraining" cycle, and gradually improve the prediction accuracy and risk identification capability.

[0080] 8) Once the self-learning process is complete, the system automatically registers the task execution results and feeds them back to the scheduling center for subsequent model optimization and task allocation management, thereby achieving closed-loop control of the entire process of database performance risk prediction.

[0081] Figure 3 This is a structural diagram of an optional database SQL performance prediction method based on multimodal feature fusion and LLM model according to an embodiment of the present invention, as shown below. Figure 3 As shown, the method is mainly implemented in four layers:

[0082] 1) Task allocation and execution layer:

[0083] This layer is primarily responsible for creating, executing, and managing database performance monitoring and risk prediction tasks. It supports both one-time rapid assessment and periodic trend monitoring modes. The task scheduling module coordinates data collection, semantic analysis, and predictive assessment processes to achieve unified task scheduling and execution within a closed loop.

[0084] 2) Data Acquisition and Preprocessing Layer:

[0085] This layer is deployed on the database host, and the Agent module is responsible for collecting performance metrics such as CPU utilization, memory usage, IOPS, SQL execution time, and lock wait time in real time. The collected data is cached, rate-limited, and formatted to generate a standardized data stream, providing high-quality input for subsequent semantic analysis and model prediction.

[0086] 3) Intelligent Analysis and Prediction Layer:

[0087] This layer performs semantic parsing on the collected SQL statements, using a Large Language Model (LLM) to transform the SQL semantics into vector representations, and forming a "semantic-performance" sample set with performance metrics. Based on historical performance sequences and semantic features, the system selects an appropriate prediction model to fit performance trends, and simultaneously integrates multimodal information such as performance time series, semantic features, logs, and configuration to generate a joint feature matrix.

[0088] 4) Risk assessment and self-learning optimization layer:

[0089] This layer calculates a risk index based on fused features, comprehensively evaluating SQL complexity, semantic differences, and performance deviation rate. When the risk index exceeds a threshold, the system automatically triggers an alert and outputs optimization suggestions. After deployment, the system continues to collect feedback data, compares predictions with actual results, and achieves model self-learning through error correction and retraining, continuously improving prediction and risk identification accuracy.

[0090] Specifically, the core technical solution of this invention is to utilize a large language model to fuse SQL semantics and performance time series to achieve database SQL performance trend prediction and intelligent risk warning. The following details the specific implementation process of this invention to achieve database SQL performance trend prediction and intelligent risk warning:

[0091] 1. The system starts the database performance monitoring and prediction task.

[0092] When the system receives an instruction for database performance monitoring and risk prediction, the system initiates the task execution process through the scheduling center. The task can be divided into two execution modes: (1) immediate execution mode: used for performance evaluation before business goes live; (2) periodic execution mode: used for periodic performance trend monitoring during database operation. When the task is created, the system defines parameters such as the target database to be monitored, sampling interval, prediction period, and risk threshold, and registers the task information in the task scheduling table.

[0093] 2. Performance data collection and standardized processing.

[0094] After the task starts, the system automatically collects performance metrics via the Agent module deployed on the database host. These metrics include CPU utilization, memory usage, disk IOPS, SQL execution time, and lock wait time. The collection process is as follows: read the system monitoring interface and database performance views (such as pg_stat_activity); cache the collected data in a local queue; and to prevent excessive I / O load and memory consumption caused by high-frequency sampling, the system introduces a rate limiting mechanism during data writing, achieving a dynamic balance between data writing rate and system load by setting the maximum sampling rate and queue depth.

[0095] When the sampling frequency exceeds the threshold, the system automatically discards redundant sampling points or uses a moving average method to smooth the sampling results, thereby ensuring data continuity and stability.

[0096] A. Perform data rate limiting and time window sharding operations.

[0097] To ensure the comparability of time-series metrics and standardize the model input for subsequent trend prediction, the system divides the continuously collected data stream into multiple fixed-length time windows (e.g., 5s, 10s, or 1min) along the time axis. The metric data within each window is aggregated using the P95 quantile function to obtain a time-slice-level performance snapshot. Where t represents the acquisition time and the window index.

[0098] B, uniformly converted into a standardized data structure.

[0099] To ensure that metrics from different dimensions can be compared on the same scale, the performance metric vectors are normalized. The Z-score standardization method is used to process each performance metric. ,in: Represented as the original value, This is represented as the mean of the feature. This is expressed as the standard deviation of the feature. This is represented as a standardized value. The standardized performance metrics data are uniformly encapsulated as a structured time-series vector, which can be represented as: .

[0100] 3. SQL semantic parsing and feature vector generation.

[0101] Once performance data collection is complete, the system automatically starts the SQL semantic analysis module to perform syntax structure recognition and complexity calculation on the collected SQL statements. The steps are as follows:

[0102] a) Parse SQL statements and identify key syntax structures such as SELECT, JOIN, and GROUP BY;

[0103] b) Calculate the SQL complexity metric: in, , , These represent the number of JOIN operations, subqueries, and groups in the SQL query, respectively. , , These are the weighting coefficients.

[0104] c) Input the parsed SQL semantics into the Large Language Model (LLM) to generate semantic vectors:

[0105] If the SQL is `SELECT t1.id, t2.name FROM t1 JOIN t2 ON t1.id = t2.id WHERE t1.value > 100;`, then the semantic vector generated after LLM embedding might be: =[0.23,-0.11,0.58,0.77,...].

[0106] 4. Semantic-performance sample set construction.

[0107] SQL semantic vector Performance metrics within the same time window Binding is performed to form a semantic-performance sample set: .

[0108] In the construction of the semantic-performance sample set, each sample record corresponds to an actual execution instance of an SQL statement and its performance, including: SQL semantic features, execution plan information, system resource status, and key performance indicators. To address the resource contention and performance interference caused by the concurrent execution of multiple SQL statements in a business database, this invention introduces a timestamp alignment mechanism and a resource consumption attribution mechanism. By aligning the SQL execution time window along the time dimension and combining the weighted allocation of multi-dimensional indicators such as CPU, IO, and lock wait, the overall system performance changes can be accurately mapped to the corresponding SQL instance, thus accurately depicting the performance characteristics and resource consumption of a single SQL statement even in high-concurrency scenarios.

[0109] Furthermore, to enhance the interpretability of sample features and the generalization ability of the model, this invention introduces database index-related information in the semantic feature extraction stage, including: index type, covering fields, index selectivity, and whether it is actually used by the optimizer.

[0110] By jointly encoding index features and execution plan features, the model can more comprehensively characterize the access path and execution cost of SQL statements, thereby providing more representative and stable training inputs for subsequent performance trend prediction and risk assessment.

[0111] Figure 4 This is a schematic diagram of an optional semantic performance sample dataset structure according to an embodiment of the present invention, such as... Figure 4 As shown, when a new SQL statement is submitted, its semantic vector is... Compared with known statement vectors in the historical sample library Compare and calculate semantic dissimilarity. Semantic dissimilarity can be defined using methods such as cosine distance or Euclidean distance. .

[0112] 5. Performance trend prediction and model selection mechanism.

[0113] The system automatically selects a suitable prediction model based on historical performance sequences and SQL semantic features.

[0114] The model selection algorithm is as follows: ,in, This represents a set of optional models (such as ARIMA, LSTM, Transformer, etc.). Let represent the training dataset, and Loss be the prediction error function on the validation set.

[0115] Taking LSTM as an example, its performance index prediction calculation process is as follows: Where w is the length of the time window. This represents the predicted performance metric for the next time step. If the historical CPU utilization sequence is {60, 65, 70, 72, 74}, and the model predicts a CPU utilization of 78% for the next time step, this indicates an upward trend.

[0116] Before and after a task goes live, the system will continuously collect key performance indicators (such as CPU utilization, IOPS, SQL response time, lock wait, etc.).

[0117] Predicted values ​​of future performance indicators are obtained through predictive models. and the average performance of the historical stable range A comparison was made. The performance deviation rate is defined as: .

[0118] 6. Multimodal feature fusion and joint representation learning.

[0119] The system further extracts features from multi-source data, including: performance time-series features. SQL semantic features Operation and maintenance log characteristics Configuration change characteristics Joint feature fusion is achieved through a cross-modal attention mechanism: .

[0120] in, ( ) represents a multi-head attention function, used to learn the correlation between different modalities. If a performance degradation event occurs simultaneously with SQL semantic features (complex JOIN) and operation logs (index rebuilding operations), the model automatically learns the high correlation between the two through the attention mechanism, thereby improving the accuracy of risk identification.

[0121] 7. Risk index calculation and intelligent early warning mechanism.

[0122] The system calculates a comprehensive risk index based on fused features: in: Performance deviation rate is the difference between the predicted value and the historical mean. SQL complexity; Semantic difference; , , Weighting coefficient.

[0123] A tiered early warning system is implemented based on the risk index: R < 0.3: Low risk, normal deployment recommended; 0.3 ≤ R < 0.6: Medium risk, SQL optimization or resource pre-allocation recommended; R ≥ 0.6: High risk, deployment delayed and expert review initiated recommended. The risk index R tier thresholds are design parameters, determined based on historical data statistical analysis or business tolerance.

[0124] 8. Self-learning and model optimization mechanism.

[0125] After the system goes live, it continuously collects operational feedback data and compares the prediction results for error. ,in This represents the prediction error (absolute error) at time point t. This represents the actual observed performance metrics (such as actual CPU utilization). This represents the performance metric obtained through model prediction. Prediction error is quantified by calculating the absolute difference between the actual and predicted values.

[0126] Automatically update model parameters based on error gradient: ,in, The learning rate is used. Through a continuous cycle of "prediction → feedback → correction," the model's performance is gradually optimized, achieving self-learning and self-adaptation. Updated model parameters, The current model parameters (i.e., the parameters from the previous training round). This indicates the step size for each update, usually a small positive number used to control the update magnitude. It is a loss function For model parameters The gradient (i.e., partial derivative) represents the sensitivity of the model parameters to the error.

[0127] Assume the predicted and actual values ​​are: predicted CPU utilization: 80%, actual CPU utilization: 75%. Then, the error... for: = |75-80|=5%, assuming the current model parameters are... Furthermore, by calculating the gradient of the error function, the gradient value is obtained. =0.02. If the learning rate =0.1, then update according to gradient descent. = -0.1 0.02= -0.002, in this case, the updated parameter We will make slight adjustments to reduce the error in the next prediction.

[0128] 9. Task closure and result registration.

[0129] Once the task is completed, the system automatically registers the prediction and risk assessment results, generates a report, and sends it back to the scheduling center for: subsequent model optimization; task execution tracking; and risk statistical analysis.

[0130] The beneficial effects of the embodiments of the present invention include: through semantic analysis, potential risks caused by the complexity and changes of SQL can be discovered in advance, overcoming the limitations of traditional methods that only look at numerical indicators; it has a closed-loop self-learning capability of "prediction-feedback-retraining", and the model can be continuously optimized, reducing long-term operation and maintenance costs; it provides a quantitative risk index and graded early warning, providing an objective and reliable basis for business launch and optimization; and it realizes the full-process automated management from data collection, analysis, early warning to optimization.

[0131] The invention will now be described in conjunction with another alternative embodiment.

[0132] Example 2

[0133] The performance risk assessment device for database query statements provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0134] Figure 5 This is a schematic diagram of an optional database query statement performance risk assessment device according to an embodiment of the present invention, such as... Figure 5 As shown, the device may include: a conversion unit 501, a data acquisition unit 502, a fusion unit 503, and an evaluation unit 504.

[0135] The transformation unit 501 is used to transform the query statement to be evaluated into a query semantic vector through a large language model. The query semantic vector is used to represent the semantic structure and execution intent of the query statement.

[0136] The acquisition unit 502 is used to acquire the running status data of the database system synchronized with the execution interval based on the execution interval of the query statement;

[0137] The fusion unit 503 is used to perform joint feature fusion on the query semantic vector and the running status data through the feature fusion model to generate a joint feature vector, wherein the joint feature vector is used to characterize the performance impact of the query statement in the context of the database system.

[0138] The evaluation unit 504 is used to evaluate the performance risk level caused by the query statement based on the joint feature vector, and output a warning signal to the operation and maintenance terminal when the risk level exceeds the preset risk threshold.

[0139] The aforementioned database query statement performance risk assessment device can first use the conversion unit 501 to convert the query statement to be assessed into a query semantic vector through a large language model. The query semantic vector is used to represent the semantic structure and execution intent of the query statement. Then, the acquisition unit 502 collects the running status data of the database system and the running status data synchronized with the execution interval of the query statement. Then, the fusion unit 503 uses a feature fusion model to perform joint feature fusion on the query semantic vector and the running status data to generate a joint feature vector. The joint feature vector is used to represent the performance impact of the query statement in the context of the database system. Finally, the assessment unit 504 assesses the performance risk level caused by the query statement based on the joint feature vector and outputs a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

[0140] In this embodiment of the invention, a deep fusion of a large language model and multimodal time-series data is employed. The large language model transforms the query statement to be evaluated into a query semantic vector representing its semantic structure and execution intent. Simultaneously, database system operating status data is collected based on the actual execution interval of the query statement, achieving precise temporal alignment between semantic features and the dynamic operating environment. Subsequently, a feature fusion model is used to perform deep joint modeling of the two in a unified representation space, generating a joint feature vector that comprehensively reflects the potential performance impact of the query statement in the current system context. Finally, the performance risk level caused by the query statement is quantitatively evaluated based on this joint feature vector, and an early warning signal is automatically triggered and pushed to the operation and maintenance terminal when the risk exceeds a preset threshold. This overcomes the limitations of traditional methods that rely solely on static indicators or isolated execution time to evaluate performance risk, achieving intelligent perception and risk prediction of the dynamic coupling relationship between the semantic intent of SQL statements and the system operating status. This improves the foresight and accuracy of database operation and maintenance, effectively prevents system performance fluctuations or service interruptions caused by high-risk queries, and solves the technical problem in related technologies where it is difficult to accurately evaluate the performance risks caused by database query statements, leading to a decline in database service stability.

[0141] Furthermore, the transformation unit includes: an acquisition module for acquiring the original text of the query statement to be evaluated; a parsing module for parsing the grammatical structure of the query statement based on the original text and extracting at least one grammatical structure feature from selection, connection, filtering, grouping, and subquery nesting levels; a concatenation module for concatenating the grammatical structure features with the original text of the query statement to obtain enhanced grammatical structure features; and an input module for inputting the enhanced grammatical structure features into a large language model, which analyzes the execution intent of the query statement and outputs a query semantic vector.

[0142] Furthermore, the acquisition unit includes: an extraction module, used to extract the start and end timestamps of the query statement from the execution log of the database system to obtain the execution interval; and a first acquisition module, used to determine the performance acquisition window based on the execution interval, and continuously acquire system performance indicators within the performance acquisition window according to a specified acquisition interval to obtain running status data, wherein the system performance indicators include at least one of the following: CPU utilization, memory usage, disk I / O throughput, lock wait time, or SQL execution time.

[0143] Furthermore, the fusion unit includes: a first processing module for performing dimensional standardization processing on the query semantic vector in the feature fusion model; a second processing module for performing sliding window aggregation processing on the running state data to obtain a running state vector that is temporally aligned with the query semantic vector; and a concatenation module for concatenating the dimensionally standardized query semantic vector and the running state vector along the feature dimension to obtain a joint feature vector.

[0144] Furthermore, the evaluation unit includes: a determination module, used to determine the semantic category to which the query semantic vector belongs and obtain the historical cluster center vector of the semantic category; a first calculation module, used to calculate the cosine distance between the joint feature vector and the historical cluster center vector to obtain the semantic dissimilarity; and a comparison module, used to compare the semantic dissimilarity with the semantic baseline threshold and determine the performance risk level based on the comparison result, wherein the semantic baseline threshold is dynamically updated based on historical semantic data.

[0145] Furthermore, the evaluation unit also includes: a matching module, used to match the query semantic vector in a preset optimization template library according to the semantic category to which it belongs, to obtain a set of optimization suggestions, wherein the set of optimization suggestions includes at least one of: index recommendation, join order adjustment, and subquery rewriting; and a push module, used to encapsulate the set of optimization suggestions and performance risk level into a structured warning signal and push it to the operation and maintenance terminal.

[0146] Furthermore, the performance risk assessment device for database query statements also includes: a second acquisition module, used to acquire the current performance indicators of the database system and obtain execution feedback data after the query statement is actually executed, following the output of a warning signal to the operation and maintenance terminal; a second calculation module, used to perform error calculation on the execution feedback data and the joint feature vector to obtain evaluation error data; and an adjustment module, used to determine the corresponding model sub-modules in the large language model and feature fusion model based on the semantic category of the query statement, and to adjust the parameters of the model sub-modules based on the evaluation error data to obtain the updated large language model and feature fusion model.

[0147] The aforementioned database query statement performance risk assessment device may also include a processor and a memory. The aforementioned conversion unit 501, acquisition unit 502, fusion unit 503, evaluation unit 504, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0148] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, the query statement to be evaluated is transformed into a query semantic vector using a large language model. The query semantic vector represents the semantic structure and execution intent of the query statement. Based on the execution interval of the query statement, runtime status data synchronized between the database system and the execution interval is collected. A feature fusion model is used to perform joint feature fusion on the query semantic vector and runtime status data to generate a joint feature vector. This joint feature vector represents the performance impact of the query statement within the context of the database system. Based on the joint feature vector, the performance risk level caused by the query statement is assessed, and a warning signal is output to the operations and maintenance terminal when the risk level exceeds a preset risk threshold.

[0149] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0150] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: converting the query statement to be evaluated into a query semantic vector through a large language model, wherein the query semantic vector is used to characterize the semantic structure and execution intent of the query statement; collecting runtime status data synchronized between the database system and the execution interval based on the execution interval of the query statement; performing joint feature fusion on the query semantic vector and runtime status data through a feature fusion model to generate a joint feature vector, wherein the joint feature vector is used to characterize the performance impact of the query statement in the context of the database system; evaluating the performance risk level caused by the query statement based on the joint feature vector, and outputting a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

[0151] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein a performance risk assessment method is provided for controlling the device where the computer-readable storage medium is located to execute any one of the database query statements in the first embodiment above when the computer program is running.

[0152] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the performance risk assessment method for database query statements of any one of the above embodiments.

[0153] Figure 6 This is a structural block diagram of an electronic device for performance risk assessment of executing database query statements according to an embodiment of the present invention, such as... Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) Processor 602, memory 604, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0154] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the database query statement performance risk assessment method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned database query statement performance risk assessment method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0155] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0156] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0157] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0158] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0159] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0160] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0161] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0162] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, 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 storage medium 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 described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0163] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for performance risk assessment of database query statements, characterized in that, include: The query statement to be evaluated is transformed into a query semantic vector through a large language model, wherein the query semantic vector is used to represent the semantic structure and execution intent of the query statement; Based on the execution interval of the query statement, collect the operating status data of the database system synchronized with the execution interval; The query semantic vector and the running status data are jointly fused using a feature fusion model to generate a joint feature vector, wherein the joint feature vector is used to characterize the performance impact of the query statement in the context of the database system. The performance risk level caused by the query statement is evaluated based on the joint feature vector, and a warning signal is output to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

2. The performance risk assessment method for database query statements according to claim 1, characterized in that, The steps of transforming the query statement to be evaluated into a query semantic vector using a large language model include: Obtain the original text of the query statement to be evaluated; Based on the original text, the syntactic structure of the query statement is parsed, and at least one syntactic structural feature from the selection, connection, filtering, grouping, and subquery nesting levels is extracted; The enhanced grammatical structure features are obtained by concatenating the grammatical structure features with the original text of the query statement; The enhanced syntactic structure features are input into the large language model, which analyzes the execution intent of the query statement and outputs the query semantic vector.

3. The performance risk assessment method for database query statements according to claim 1, characterized in that, The steps of collecting runtime status data of the database system synchronized with the execution interval based on the execution interval of the query statement include: The execution interval is obtained by extracting the start and end timestamps of the query statement from the execution log of the database system. The performance acquisition window is determined based on the execution interval, and the system performance indicators are continuously acquired within the performance acquisition window according to the specified acquisition interval to obtain the running status data. The system performance indicators include at least one of the following: CPU utilization, memory usage, disk I / O throughput, lock wait time, or SQL execution time.

4. The performance risk assessment method for database query statements according to claim 1, characterized in that, The step of generating a joint feature vector by performing joint feature fusion on the query semantic vector and the running status data through a feature fusion model includes: In the feature fusion model, the query semantic vector is subjected to dimensionality standardization. The running status data is subjected to sliding window aggregation processing to obtain a running status vector that is temporally aligned with the query semantic vector; The query semantic vector, after dimensional standardization, is concatenated with the running state vector along the feature dimension to obtain the joint feature vector.

5. The performance risk assessment method for database query statements according to claim 1, characterized in that, The steps for assessing the performance risk level caused by the query statement based on the joint feature vector include: Determine the semantic category to which the query semantic vector belongs, and obtain the historical cluster center vector of the semantic category; The semantic dissimilarity is obtained by calculating the cosine distance between the joint feature vector and the historical cluster center vector. The semantic difference is compared with the semantic baseline threshold, and the performance risk level is determined based on the comparison result, wherein the semantic baseline threshold is dynamically updated based on historical semantic data.

6. The performance risk assessment method for database query statements according to claim 5, characterized in that, The step of outputting a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold includes: Based on the semantic category to which the query semantic vector belongs, a matching is performed in a preset optimization template library to obtain an optimization suggestion set, wherein the optimization suggestion set includes at least one of: index recommendation, join order adjustment, and subquery rewriting; The set of optimization suggestions and the performance risk level are encapsulated into a structured warning signal and pushed to the operation and maintenance terminal.

7. The performance risk assessment method for database query statements according to claim 1, characterized in that, After outputting the warning signal to the operation and maintenance terminal, the method further includes: After the query statement is actually executed, the current performance indicators of the database system are collected to obtain execution feedback data; Error calculation is performed on the execution feedback data and the joint feature vector to obtain evaluation error data; Based on the semantic category of the query statement, the corresponding model sub-modules in the large language model and the feature fusion model are determined. Based on the evaluation error data, the parameters of the model sub-modules are adjusted to obtain the updated large language model and the feature fusion model.

8. A performance risk assessment device for database query statements, characterized in that, include: The transformation unit is used to transform the query statement to be evaluated into a query semantic vector through a large language model, wherein the query semantic vector is used to characterize the semantic structure and execution intent of the query statement; The acquisition unit is used to acquire the running status data of the database system synchronized with the execution interval based on the execution interval of the query statement; The fusion unit is used to perform joint feature fusion on the query semantic vector and the running status data through a feature fusion model to generate a joint feature vector, wherein the joint feature vector is used to characterize the performance impact of the query statement in the context of the database system. The evaluation unit is used to evaluate the performance risk level caused by the query statement based on the joint feature vector, and output a warning signal to the operation and maintenance terminal when the risk level exceeds a preset risk threshold.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the performance risk assessment method for database query statements according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the performance risk assessment method for database query statements according to any one of claims 1 to 7.

Images