Intelligent optimization method and device for query statement, equipment and medium

Abstract

The invention relates to the technical field of artificial intelligence, can be applied to business scenes such as financial science and technology and medical health, and discloses an intelligent optimization method, device and equipment for query statements and a medium. The method comprises the steps of recording execution plan information and resource consumption information of an original query statement, generating original execution information, preprocessing the original query statement and the original execution information to generate preprocessing data, extracting feature information from the preprocessing data, generating optimization information through a pre-trained optimization model based on the feature information, and sending the optimization information to a server. And according to the optimization information, adjusting the content or execution mode of the original query statement, and generating an optimization query instruction. According to the method, the feature information is extracted by monitoring the actual query behavior and combining the execution performance, and the optimization strategy is generated by utilizing the training model, so that the automatic optimization of the original query statement is realized, the manual intervention cost is reduced, and the intelligent adaptation capability of the query performance is improved.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to a method, device, equipment and storage medium for intelligent optimization of query statements. Background Art

[0002] Against the backdrop of the rapid growth of big data, SQL, as a core tool for data query and processing, has been widely used in various database systems, supporting key scenarios such as business analysis, report generation, and real-time monitoring. However, existing technologies still rely heavily on manual optimization for SQL query statements. SQL performance bottlenecks are becoming increasingly prominent, especially in complex queries, multi-table joins, and large data processing scenarios. Fluctuations in resource usage, unstable execution plans, and incorrect index strategy selection during query execution often lead to increased response delays and decreased system throughput, severely impacting business continuity and user experience.

[0003] In the fintech business sector, scenarios such as real-time risk control, credit approval, and transaction behavior analysis require database systems to possess extremely high query response efficiency and stability. Existing technologies often rely on experienced database administrators to manually analyze execution plans and adjust query structures. However, when faced with tens of thousands of complex, dynamic queries, manual intervention is inefficient and slow to respond, easily leading to system resource misallocation and delayed risk assessment, further impacting the real-time and accuracy of financial decision-making.

[0004] In the healthcare sector, services such as electronic medical record access, medical image indexing, and intelligent diagnostic data aggregation require the rapid and accurate execution of large numbers of SQL queries. Existing technologies for processing medical data are time-consuming and inaccurate due to complex query structures, high field dimensionality, and extensive historical data. Traditional manual SQL optimization methods also struggle to adapt to the heterogeneous data and varying query patterns across hospitals and systems, severely limiting the responsiveness of medical services and system scalability.

[0005] Furthermore, as business needs evolve dynamically, existing optimization mechanisms struggle to quickly adjust and respond to real-time query behavior, execution status, and system load. On one hand, SQL statement optimization lacks contextual awareness and execution feedback mechanisms, making it difficult to accurately identify performance bottlenecks. On the other hand, the lack of intelligent, automated optimization strategy execution makes traditional optimization methods difficult to generalize and apply in large-scale, multi-scenario systems.

[0006] Therefore, existing technologies have the following significant shortcomings when it comes to complex SQL optimization tasks: the optimization process relies on manual experience, has low execution efficiency, and does not respond promptly to system status changes. This makes it difficult to meet the automated optimization needs in scenarios such as finance and healthcare, which have high query performance requirements and frequent business changes. Summary of the Invention

[0007] The main purpose of the present invention is to provide an intelligent optimization method, device, equipment and storage medium for query statements, aiming to solve the technical problems that the existing technology relies on manual experience to optimize queries, resulting in low efficiency and inability to dynamically adapt to changes in data and query requirements.

[0008] To achieve the above objectives, the present invention provides an intelligent query optimization method, comprising:

[0009] Using a data monitoring module to monitor the operation behavior of the data processing system, and capturing the original query statement through the data monitoring module;

[0010] Recording execution plan information and resource consumption information of the original query statement in the data processing system, and generating original execution information based on the execution plan information and resource consumption information;

[0011] Preprocessing the original query statement and the original execution information to generate preprocessed data;

[0012] extracting feature information from the preprocessed data;

[0013] Based on the feature information, generating optimization information through a pre-trained optimization model;

[0014] The content or execution mode of the original query statement is adjusted according to the optimization information, and an optimized query instruction is generated according to the adjusted content or execution mode.

[0015] Furthermore, to achieve the above-mentioned purpose, the present invention provides an intelligent query optimization device, comprising:

[0016] A query monitoring module, configured to monitor the operation behavior of the data processing system using the data monitoring module and capture the original query statement through the data monitoring module;

[0017] an execution tracking module, configured to record execution plan information and resource consumption information of the original query statement in the data processing system, and generate original execution information based on the execution plan information and resource consumption information;

[0018] A data preprocessing module, configured to preprocess the original query statement and the original execution information to generate preprocessed data;

[0019] A feature extraction module, configured to extract feature information from the preprocessed data;

[0020] An optimization reasoning module, configured to generate optimization information based on the feature information through a pre-trained optimization model;

[0021] The query rewriting module is used to adjust the content or execution mode of the original query statement according to the optimization information, and generate an optimized query instruction according to the adjusted content or execution mode.

[0022] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and an intelligent optimization program for query statements stored in the memory and capable of running on the processor. When the intelligent optimization program for query statements is executed by the processor, the steps of the intelligent optimization method for query statements as described above are implemented.

[0023] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which an intelligent optimization program for query statements is stored. When the intelligent optimization program for query statements is executed by a processor, the steps of the intelligent optimization method for query statements as described above are implemented.

[0024] Beneficial effects: The present invention relates to the field of artificial intelligence technology and can be applied to business scenarios such as financial technology and medical health. It discloses an intelligent optimization method, device, equipment and medium for query statements, including: setting a data monitoring module to monitor the operating behavior of the data processing system and capture the original query statement, recording the execution plan information and resource consumption information of the original query statement in the data processing system, generating original execution information, pre-processing the original query statement and the original execution information to generate pre-processed data, extracting feature information from the pre-processed data, generating optimization information based on the feature information through a pre-trained optimization model, adjusting the content or execution method of the original query statement according to the optimization information, and generating an optimized query instruction. The present invention realizes the automatic adjustment of the original query statement by monitoring the query behavior actually running in the system, extracting feature information in combination with the execution plan and resource consumption information, and dynamically generating optimization information using a pre-trained optimization model, effectively improving the intelligence and adaptability of SQL optimization, reducing the cost of manual intervention, and enhancing the adaptive ability of query performance in different business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0026] Figure 1 A schematic diagram of an application environment of an intelligent optimization method for query statements according to an embodiment of the present invention;

[0027] Figure 2 This is a flow chart of an embodiment of an intelligent query optimization method according to the present invention;

[0028] Figure 3 This is a functional module diagram of a preferred embodiment of the intelligent query optimization device of the present invention;

[0029] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0030] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0032] The intelligent optimization method for query statements provided by the embodiment of the present invention can be applied in Figure 1 In an application environment, the user terminal communicates with the server terminal through a network. The server terminal can set a data monitoring module through the user terminal to monitor the operation behavior of the data processing system and capture the original query statement, record the execution plan information and resource consumption information of the original query statement in the data processing system, generate original execution information, pre-process the original query statement and the original execution information to generate pre-processed data, extract feature information from the pre-processed data, generate optimization information based on the feature information through a pre-trained optimization model, adjust the content or execution mode of the original query statement according to the optimization information, and generate an optimized query instruction. The present invention realizes the automatic adjustment of the original query statement by monitoring the query behavior actually running in the system, extracting feature information in combination with the execution plan and resource consumption information, and dynamically generating optimization information using a pre-trained optimization model, effectively improving the intelligence and adaptability of SQL optimization, reducing the cost of manual intervention, and enhancing the self-adaptation ability of query performance under different business scenarios. Among them, the user terminal can be but is not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server terminal can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0033] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of the intelligent optimization method for query statements provided by the present invention. It should be noted that although the flow chart shows a logical order, in some cases, the steps shown or described may be performed in a different order than here.

[0034] like Figure 2 As shown, the intelligent optimization method for query statements proposed by the present invention includes the following steps:

[0035] S10, using a data monitoring module to monitor the operation behavior of the data processing system, and capturing the original query statement through the data monitoring module;

[0036] In this embodiment, the data monitoring module is used to achieve real-time perception and instruction capture of database query behavior. The overall process includes module deployment, communication protocol configuration, behavior monitoring logic definition, identification mechanism establishment and statement extraction processing. In actual deployment, it is necessary to initialize the proxy component with data access capabilities and configure the data communication protocol it supports to match the target system, such as using JDBC or ODBC standard interface protocols to be compatible with mainstream data processing system structures. This configuration stage requires setting the component's input channel, including the receiving port and the access path for parsing statements, to ensure that the monitoring agent can access the data channel without interference.

[0037] Component binding behavior involves attaching the monitoring logic to the data system's query receiving port and parsing engine layer to obtain the original request data stream and its parsing process. This process requires injecting binding code during system initialization, or weaving the monitoring module into the query parsing process through a runtime proxy mechanism. This is typically achieved through structural embedding using bytecode enhancement or kernel plug-in technology. During the continuous monitoring phase, the component enters event-driven mode, polling the content stream of the target channel periodically or based on trigger conditions, and analyzing the contextual information of the data interaction, such as TCP connection metadata, query submission behavior, and operation type fields.

[0038] During identification, a high-confidence discriminant model should be established to distinguish query-type operations from non-query instructions. Specifically, this can be achieved by quickly pre-classifying SQL statements based on keywords such as SELECT, INSERT, and UPDATE. Alternatively, a command classifier based on state transition diagrams can be used to establish operation intent mapping rules. Statement extraction requires obtaining the complete text of the original query statement at the parsing structure level. This is typically achieved by intercepting the syntax parser front-end and extracting standardized statement expressions, including removing transmission protocol encoding and standardizing escape characters.

[0039] A variety of implementation strategies can be used to deploy monitoring modules on different database platforms. In PostgreSQL, you can leverage its extension mechanism to install logical hook functions, attaching monitoring logic to the hook point before statement parsing to capture and classify incoming query requests. In MySQL, you can use ProxySQL or MaxScale as an intermediate layer to implement SQL statement routing control and monitoring log synchronization, while forwarding identification results to subsequent processing modules through a plug-in mechanism. In distributed data processing platforms based on Spark SQL or Hive, you can intercept the query compiler's input stream or extend the Catalog API to capture externally submitted SQL commands, extracting and encapsulating the original query statements.

[0040] A distributed monitoring architecture can also be used to monitor multiple query sources simultaneously. For example, in a data lake scenario, since query requests may originate from multiple microservices or data visualization platforms, multiple monitoring proxy nodes can be deployed at the service gateway or data middleware layer. Monitoring policies can be coordinated through a unified configuration center to ensure full coverage of the original query statements. Furthermore, asynchronous channels can be used to decouple monitoring logic from query execution, avoiding performance interference with the actual query process.

[0041] Example: In the healthcare sector, medical record retrieval, drug inventory query, and appointment record access in hospital information systems are typically completed through standard SQL interfaces. The system can embed a monitoring module at the query entry point of the HIS or data center to capture queries submitted by doctors or managers in real time, providing a complete data source for subsequent analysis, helping to optimize slow queries and reduce system load.

[0042] In the fintech sector, customer transaction behavior analysis, fraud detection data queries, and automated report generation often require complex multi-table joins. Deploying a monitoring module at the data control layer enables accurate acquisition of SQL call information across multiple scenarios, providing stable input for model optimization and execution adjustments, and improving the accuracy and adaptability of automated tuning.

[0043] This embodiment establishes a monitoring module with data channel binding capabilities and high-precision behavior recognition capabilities, effectively achieving real-time capture and complete extraction of query behavior in the data processing system. Without relying on the database engine itself to expose logs or monitoring interfaces, the system can obtain query statement source information, enabling pre-emptive intervention and subsequent analysis, providing a structurally consistent data source for subsequent execution feature extraction and model inference. This mechanism significantly improves the coverage and stability of query statement acquisition, effectively avoiding the format heterogeneity issues caused by traditional log reliance.

[0044] S20, recording execution plan information and resource consumption information of the original query statement in the data processing system, and generating original execution information according to the execution plan information and resource consumption information;

[0045] In this embodiment, the execution plan and resource consumption information of the original query statement in the data processing system is recorded, requiring data collection and identification management through a pluggable tracking mechanism combined with runtime resource monitoring. Execution plan information refers to the set of physical execution strategies formed by the database system after parsing and optimizing the SQL statement. It typically takes the form of a logical operation tree, physical operation nodes, and index usage paths. Resource consumption information includes dynamic metrics such as CPU usage, memory usage, I / O reads and writes, and network transmission volume during execution.

[0046] In order to achieve full-link tracking of the query execution process, a unique tracking identifier needs to be attached to the original query statement layer. This identifier can be a UUID, a hash value, or a composite identifier generated by business-related fields, which is used throughout the statement in the parsing, optimization, scheduling, and execution stages to ensure the accuracy of subsequent information associations. At the execution layer, enable the execution tracker component to capture execution link information. This component should support docking with the database execution plan interface, such as extracting logical plans and actual execution path data through EXPLAIN ANALYZE, Query Profile API, or log enhancement interface. The record of execution plan information should include indicators such as the execution operator sequence, operation time, data size, index information used, and parallelism.

[0047] Resource consumption information collection requires using system-level monitoring interfaces or database-embedded monitoring tools. For example, in PostgreSQL, statement execution resource metrics can be obtained through views such as pg_stat_statements and pg_stat_activity. In Spark SQL environments, task execution metrics can be collected through event listeners and aggregated into resource consumption reports. The collection granularity must cover the entire lifecycle, including compile time, scheduling wait time, execution duration, and abnormal interruptions.

[0048] All execution plan information and resource consumption information must be structured and integrated using tracking identifiers as index fields to generate raw execution information. This structure must ensure the reconstructibility and traceability of the content, while also providing a clear data hierarchy for subsequent data processing and model input.

[0049] During implementation, a unique tracing identifier can be constructed for each original query statement and embedded into the query metadata through syntax rewriting. This automatically carries tracing information when the query is executed in the system. For example, in Spark SQL, a tracing identifier can be bound to each job by setting a Query Tag or Job Group. In traditional databases such as Oracle or MySQL, tracing identifiers can be injected into connection session variables, and execution information corresponding to the statement can be extracted through audit logs or extension plugins.

[0050] The execution tracker component can be implemented based on the system's internal hook mechanism or audit API integration. For database platforms that support execution path visualization (such as SQL Server's Query Store and Oracle's Execution Plan Cache), structured execution plans can be obtained directly through the system interface. For systems that do not directly support this, the execution path can be indirectly constructed by parsing query logs, analyzing the execution graph structure, or reconstructing the intermediate semantic tree.

[0051] The method for obtaining resource consumption information can be adapted according to the deployment environment: in a containerized environment, Prometheus+Exporter can be used to monitor database container resources; in a physical cluster, fine-grained operating indicators can be obtained through system indicator collectors (such as dstat, perf, and nmon), and aggregated based on the timestamps of query scheduling events.

[0052] Example: In the healthcare sector, complex patient searches and multi-dimensional medical data queries often involve nested subqueries and cross-table joins. The system can use tracking tags to record the execution time and plan differences of queries submitted by doctors over different time periods, identify performance degradation points, and generate feedback. This mechanism can be embedded in hospital data centers or electronic medical record analysis platforms to optimize query engine scheduling and indicator dashboard response times.

[0053] In the fintech business field, such as queries on high-frequency trading behavior data or risk rule retrieval, the SQL execution plan will change dynamically with the data scale and index status. Through the execution tracking and resource collection mechanism, it is possible to discover the changing trends of query performance with market fluctuations or data writing status, thereby assisting in generating dynamic execution adjustment suggestions, effectively reducing the system peak load and improving analysis response capabilities.

[0054] This implementation combines the collection and structured recording of the plan structure and resource behavior throughout the execution of the original query statement, providing dual support for subsequent analysis covering both execution semantics and performance metrics. Compared to optimization approaches that rely solely on SQL text analysis or static rules, this mechanism can reveal real-world system bottlenecks and optimization potential, enhancing the interpretability and generalizability of the optimization model, and improving the system's dynamic tuning and adaptability for complex queries.

[0055] S30, preprocessing the original query statement and the original execution information to generate preprocessed data;

[0056] In this embodiment, the original query statement and original execution information are preprocessed to construct a structured and standardized input data format that is more suitable for machine learning model understanding and processing. Query statements typically contain various forms of SQL syntax structures, comment characters, line breaks, redundant spaces and other non-semantic content. Therefore, it is necessary to perform a cleaning operation to remove semantically irrelevant characters, retain structural elements with grammatical and logical value, and generate a cleaned query statement. The cleaning operation can be implemented by a lexical analyzer or a custom regular parser to remove comment characters such as -- or / ** / to wrap content, and standardize visually irrelevant symbols such as uppercase and lowercase letters, spaces, etc.

[0057] Raw execution information may contain noise, statistical anomalies, inconsistent units, missing fields, and other issues, necessitating numerical cleaning during the preprocessing phase. This typically involves using outlier detection algorithms (such as the Z-score and boxplot method) to identify and remove atypical execution metrics. This also involves completing field mappings and unifying units, such as converting MB / s to KB / ms, to ensure consistency in subsequent input.

[0058] After cleaning, the query statement needs to be converted into a vectorized representation. Vectorization transforms natural language SQL expressions into structured feature inputs. Common methods include TF-IDF representation, Word2Vec embedding, SQL tree expansion, or embedding representation generated by encoder models (such as BERT for SQL). This conversion process preserves the query statement's operational logic, structural length, and semantic structure, constructing discriminative feature dimensions for model input.

[0059] Similarly, the cleaned execution information also requires numerical normalization. Normalization compresses the data range, improves model convergence stability, and avoids gradient imbalances caused by differences in numerical magnitude between dimensions. Normalization methods include Min-Max scaling, Z-score normalization, or distribution mapping.

[0060] Finally, the query vector representation is structurally combined with the normalized execution information to generate a preprocessed data structure of uniform dimension, usually organized in the form of JSON, Tensor or DataFrame, and used as input for subsequent model reasoning.

[0061] In practice, an internal query preprocessing rule table can be defined to conditionally strip comments, spaces, indents, and line breaks to prevent syntax errors. For example, SQL keywords can be identified through character-by-character parsing to construct a cleansed sequence. This operation is performed in the data collection gateway or access layer module, ensuring data standardization before entering the main processing pipeline.

[0062] Execution information is cleaned by configuring a metric integrity rule base. For each metric, we set missing fill logic, upper and lower limits for outliers, and a unified unit conversion table. For example, if the I / O count field recorded in the execution plan contains a negative value, it is replaced with the device driver's default maximum read and write count and marked for archiving. Metrics in KB are converted to a unified MB unit using pre-set conversion parameters.

[0063] Sentence vector generation doesn't rely on off-the-shelf models, but instead employs a rule-driven feature extraction approach. The system defines several structural features, such as operator counters, nesting levels, and field usage density, and constructs a fixed-length vector template. The template then sequentially populates the vector with the number of occurrences of each structure to generate the structure vector.

[0064] Normalization of the information vector is also based on an internal numerical mapping function. For example, a maximum threshold T is set for the CPU time, and the original value is divided by T to ensure that the normalized result is between [0, 1]. If T is exceeded, the result is set to 1 to indicate saturation.

[0065] Finally, the system will concatenate the generated query vector and the normalized execution information to form a data row with a unified structure, which will be stored in a cache queue or storage module for subsequent model loading.

[0066] Example: In healthcare scenarios, doctors generate complex query statements containing patient screening criteria. These statements may contain multiple nested columns or temporary table definitions. During preprocessing, the statements are cleaned of possible misspellings, comments, or non-standard spaces. The statements are then converted into structured vectors to facilitate the generation of optimization recommendations, effectively improving the execution efficiency of complex queries on the case database.

[0067] In FinTech scenarios, queries are often manually written by analysts or generated by scripts. Their execution data may contain outliers due to network jitter or fluctuations in computing resources. Preprocessing effectively identifies and removes these noise indicators, unifies the units of execution time, memory, and I / O data, and converts them into comparable standard vectors, providing a stable and optimized data foundation for risk control and behavioral analysis.

[0068] This implementation, through preprocessing operations such as cleaning, vectorization, and normalization, unifies the structure of original unstructured SQL statements and multi-dimensional execution metrics. This allows subsequent optimization models to input data in a more consistent and learnable format, improving the model's generalization performance and inference accuracy. Furthermore, the preprocessing process eliminates anomalies and standardizes the model, ensuring it is not affected by outliers, thereby enhancing overall optimization reliability and controllability.

[0069] S40, extracting feature information from the preprocessed data;

[0070] In this embodiment, preprocessed data typically consists of two components: semantically regularized query structure information and a normalized representation of execution behavior metrics. This stage requires converting the structural and execution information into fixed-dimensional feature vectors that can be used for subsequent model processing. The feature information extraction process essentially involves quantitatively modeling query intent, structural complexity, and resource sensitivity, enabling the optimization model to accurately identify key factors impacting performance.

[0071] The fields that can be extracted from the structural information include statement type (such as SELECT, UPDATE, JOIN), nesting level depth, field usage frequency, conditional filtering complexity, aggregation function usage, and the number of sorted fields. These fields are mapped to numerical features using structural syntax rules. For example, nesting level is represented by syntax tree depth, field usage frequency is counted by scanning clauses such as SELECT and WHERE, and conditional complexity is measured by the number of Boolean expression nodes.

[0072] Extractable fields from execution information include CPU time, memory usage, I / O access volume, logical read / write ratio, and cache hit rate. Discretizing, normalizing, or binning these numerical metrics makes feature representation more stable and facilitates model generalization. This process can be implemented through lookup tables, function mapping, or statistical threshold control, without relying on any external components or libraries.

[0073] Structural and performance features are merged in a fixed order to form a complete feature vector. Each dimension represents a semantic or resource metric and establishes a one-to-one mapping relationship with the original query content. This mapping relationship supports retrospective adjustments to the optimization model path and serves as a reference for evaluating optimization results.

[0074] During feature design, to improve the ability to discern different behavior patterns, you can also design composite features. For example, you can use the product of the number of JOINs and the logical read / write ratio as a resource intensity factor, or the weighted sum of the number of aggregate functions and the number of sorted fields as a potential blocking risk factor. These composite features are generated through internal build logic rather than relying on external models or specific libraries.

[0075] In actual deployment, the system feeds each piece of preprocessed data into the feature parsing module. This module internally constructs a set of structure field mapping tables and performance field reduction rules to analyze and transform the input data field by field. The structure mapping table defines various SQL keywords and their semantic categories and configures the numerical conversion method corresponding to each structural feature. For example, nested levels are counted using a bracket matching algorithm, and the number of JOIN structures is determined through regular pattern matching.

[0076] The conversion of performance indicators is processed through boundary checking and value normalization rules. For example, the CPU time is set to a maximum limit of T, and the actual collected value is divided by T to form a standard feature. If there is an abnormal logical read / write ratio, the quantile boundary is reset to the median level.

[0077] The feature combination process is achieved through matrix stacking. Each feature template is a fixed-length vector structure. The system sequentially merges them according to preset splicing rules to ensure that all feature dimensions remain consistent across different queries. This vector structure is cached or batch-written to the model serving component for optimized inference calls.

[0078] Example: In a healthcare scenario, a user queries medication usage records for a high-risk population for a chronic disease. The SQL statement may contain multiple JOINs and aggregate functions. The system extracts structural features such as the number of JOINs, the complexity of the WHERE condition, and the number of sorted fields, as well as performance characteristics such as CPU usage and cache hit rates from historical executions. This generates a comprehensive feature vector to assist the model in determining whether to add indexes or adjust the subquery structure.

[0079] In FinTech scenarios, analysts analyze user trading behavior using complex grouping and window functions, often involving numerous nested aggregations and window sorting operations. The system extracts structural features such as field usage density, the number of aggregation functions, and the span of sorted fields. Combined with memory usage and logical I / O metrics from execution information, it constructs a transaction behavior feature vector. This helps the model determine whether to adjust execution methods or restrict query scope, thereby reducing execution latency and resource usage.

[0080] This embodiment builds a unified feature extraction mechanism across both structural and behavioral dimensions, enabling a multi-dimensional representation of query intent, resource usage, and potential bottlenecks, enhancing the model's ability to identify key performance influencing factors. This mechanism not only improves the pertinence and generalization of optimization recommendations, but also reduces model dependency, making it applicable to query optimization processes across a wide range of business scenarios.

[0081] S50, generating optimization information based on the feature information through a pre-trained optimization model;

[0082] In this embodiment, after receiving structured feature information, the system inputs it into a trained model structure. The model then predicts structural bottlenecks and performance degradation points for the current query load and generates adjustment recommendations. This process involves four key steps: model input format alignment, inference execution, and output result interpretation and formatting.

[0083] Model input format alignment involves the system reordering the dimensions of extracted feature information, converting data types, and filling in missing values ​​to ensure it fully conforms to the model's input structure. For example, sparse feature dimensions are represented using sparse matrix encoding; categorical features are indexed using vocabulary mapping; and continuous features are normalized to a set range.

[0084] During the inference execution phase, the system calls the inference module to perform one or more rounds of forward propagation on the input features, generating an intermediate output containing potential optimization suggestions. This intermediate output is typically a multi-dimensional vector structure that encodes the preference weights, confidence scores, and recommended structural adjustments for multiple feasible optimization paths.

[0085] Model output interpretation requires the system to map, decode, and semantically restore the encoded content within the inference results. This process constructs a parsing mapping table and a set of structural reconstruction rules to restore the optimization semantics corresponding to each dimension value in the vector into a concrete expression. For example, this identifies optimization instructions such as "field order adjustment," "WHERE condition simplification," "grouping strategy change," and "subquery rewrite."

[0086] During the final output formatting stage, the system performs syntax review, semantic verification, and structural encapsulation on the decoded optimization instructions to ensure their executable and logical consistency, and outputs the optimization information in the form of structured data for subsequent query statement rewriting and execution parameter configuration calls.

[0087] In actual implementation, the system loads an optimized model structure, which can be based on a lightweight neural network, decision tree ensemble, sequence encoding network, or other common prediction structures. The optimized model is deployed in the inference service component to support concurrent calls and low-latency prediction.

[0088] During the input processing phase, the system maps feature information into model input tensors, automatically filling in missing dimensions and normalizing standard deviations. The inference engine is then invoked for online inference, generating an intermediate representation. This intermediate representation includes a scoring vector for multiple optimization recommendations. Each recommendation includes a type number, parameter reference values, and impact factors.

[0089] The system decodes the scoring vector. For example, if the highest-scoring item is type 3 and the parameter value is 0.82, it is mapped to the action suggestion "Merge subqueries into nested views" with the expected reduction in logical cost. The built-in syntax reconstructor verifies the reconstruction logic of the suggestion and converts the available suggestions into a structured optimization information set, including the recommended target, affected fields, reconstruction strategy, and execution plan adjustment plan.

[0090] The system will also eliminate unexecutable suggestions to ensure that the output results are logically and grammatically feasible.

[0091] Example: In a healthcare scenario, a query involves querying multi-cycle medication records for chronic disease patients. The query includes a time window JOIN across multiple tables and conditional filtering logic. The optimization model identifies high redundancy in the JOIN fields and a missing index for the sort field. The inference results suggest collapsing the subquery into a view and adjusting the field order. The system then outputs optimization information indicating the specific index strategy change path in the execution plan.

[0092] In a FinTech business scenario, analysts were analyzing the daily average balance fluctuations of high-frequency trading accounts. The query contained window functions and nested subqueries, resulting in long execution times. The model analyzed the window function parameters and I / O ratios in the feature vectors and identified a sorting bottleneck. The resulting optimization information recommended adding sort fields to the federated index and pre-aggregating some intermediate tables to improve query efficiency and reduce response time.

[0093] This embodiment introduces a model-based reasoning mechanism to generate optimization information, avoiding the problems of insufficient coverage and misjudgment caused by traditional reliance on empirical rules. This mechanism utilizes multidimensional structural and performance feature inputs to accurately identify performance bottlenecks and recommend adjustment paths, significantly improving the accuracy and adaptability of optimization results. Unlike static rule matching, model reasoning can reflect the dynamic relationship between the current system state and the query structure in real time, achieving fine-grained, high-precision query performance improvements.

[0094] S60: Adjust the content or execution mode of the original query statement according to the optimization information, and generate an optimized query instruction according to the adjusted content or execution mode.

[0095] In this embodiment, after receiving the optimization information, the system determines the type of optimization operation contained in the optimization information and adjusts the original query structure or execution configuration accordingly. Optimization operation types are generally categorized into two types: query statement text rewriting and execution parameter configuration. Operation type identification is performed based on the operation identification field in the structured optimization information. This field is clearly mapped during the optimization information generation phase and indicates the type of change to be made to the query statement.

[0096] For text rewriting operations, the system reconstructs the logical structure of the original query statement based on the target clauses, suggested structures, and semantic rewriting parameters in the optimization information. This process includes clause replacement, predicate simplification, field reordering, and nested function expansion. For example, nested subqueries can be replaced with JOIN operations, or filter conditions that don't match the index can be prepended to improve index utilization.

[0097] For execution parameter configuration operations, the system parses the optimization information contained in the execution parameter adjustment items, such as enabling parallel processing, adjusting execution plan hints, modifying optimizer behavior, and setting a memory usage limit. The system embeds these parameters into the query statement or sets the execution context within the execution environment, allowing the original query to be received and parsed by the execution engine in a new way while maintaining the original query's semantics.

[0098] When multiple optimization operation types are present, the system constructs multiple candidate query structures and performs syntax validation and logical consistency verification on each candidate structure. All verified versions are sent to the optimization instruction generation module, which encapsulates them into optimized query instructions.

[0099] The optimized query instructions finally outputted are a set of semantically equivalent and structurally adjusted query statements and their execution environment configurations, which are complete enough to be directly sent to the query execution engine.

[0100] In its implementation, after loading the optimization information data structure, the system uses the type recognition logic module to extract the operation type field and determine whether statement-level rewriting is necessary. If a text-structure rewrite is required, the query reconstruction component is invoked to load the parse tree of the original statement and modify the corresponding subtree according to the target clauses and adjustment strategies described in the optimization information, ultimately regenerating a structured statement.

[0101] For example, if optimization information indicates changing an unequal JOIN to a HASH JOIN, the system locates the JOIN node and inserts the corresponding optimizer hint or uses rewrite rules to replace the join structure. Another example is if an aggregate function is pushed down, the system moves the AGGREGATE node to a mergeable location and adjusts the logical execution order.

[0102] If the optimization information type is execution parameter configuration, the system parses parameter key-value pairs, such as "enable_parallel=true", "join_collapse_limit=1", "set work_mem=64MB", and writes these parameters into the execution context during query precompilation.

[0103] For complex optimization scenarios, the system uses a query validation module to verify that the rewritten query is logically equivalent to the original query, ensuring that the result set does not have semantic deviations. All valid results are written into the optimization instruction structure and marked as executable.

[0104] Example: In healthcare, a user submitted a query request to retrieve a time-based comparison table of a patient's medication records and diagnosis results across multiple follow-up visits. The original query statement contained multiple nested views and field filter conditions that missed indexes. The system identified query restructuring suggestions from optimization information, automatically rewriting the filter order in the WHERE clause and using optimizer hints to force the use of the primary index path. The resulting optimized query instruction improved query response speed and reduced the cost of generating temporary tables.

[0105] In a FinTech business scenario, the backend service system regularly runs queries analyzing user fund flow trends. The original query used multiple window functions and repeated JOIN logic. Optimization information identified redundant JOINs and sorting bottlenecks. Based on this information, the system automatically merged the JOIN logic and added memory allocation parameters to improve the efficiency of the sorting phase. The resulting optimized query reduced execution time fluctuations and significantly lowered CPU utilization, ensuring the stable operation of large-scale periodic tasks.

[0106] This embodiment utilizes a statement rewriting and execution mode reconfiguration mechanism driven by structural optimization information to efficiently transform the optimization model's results into a deployable query structure, avoiding subjective biases and grammatical errors associated with manual understanding and rewriting. This mechanism implements closed-loop optimization logic for automatic judgment, matching, and rewriting, effectively improving the performance and resource utilization efficiency of complex SQL statements in actual execution, and possessing cross-scenario generalization capabilities.

[0107] The present invention relates to the field of artificial intelligence technology and can be applied to business scenarios such as financial technology and medical health. A method, device, equipment and medium for intelligent optimization of query statements are disclosed, including: setting a data monitoring module to monitor the operating behavior of a data processing system and capture original query statements, recording the execution plan information and resource consumption information of the original query statements in the data processing system, generating original execution information, pre-processing the original query statements and the original execution information to generate pre-processed data, extracting feature information from the pre-processed data, generating optimization information based on the feature information through a pre-trained optimization model, adjusting the content or execution mode of the original query statement according to the optimization information, and generating an optimized query instruction. The present invention realizes automatic adjustment of the original query statement by monitoring the query behavior actually running in the system, extracting feature information in combination with the execution plan and resource consumption information, and dynamically generating optimization information using a pre-trained optimization model, effectively improving the intelligence and adaptability of SQL optimization, reducing the cost of manual intervention, and enhancing the adaptive ability of query performance under different business scenarios.

[0108] In one embodiment, the above step S10 includes:

[0109] S101, initializing a monitoring agent component and configuring a communication protocol of the monitoring agent component so as to interface with a data processing system;

[0110] S102, binding the monitoring proxy component to the query receiving port and query parsing engine of the data processing system;

[0111] S103, activating the continuous monitoring function of the monitoring agent component to continuously scan the bound query receiving port and the operation behavior of the query parsing engine;

[0112] S104, identifying query submission behaviors from the monitored operation behaviors and filtering non-query operations;

[0113] S105: Capture the complete query statement text from the identified query submission behavior as the original query statement.

[0114] In this embodiment, initializing the monitoring proxy component is a preparatory step before the system realizes the connection with the data processing system. The proxy component can be deployed in the form of an embedded module, an independent service or a sidecar container, and has a configurable communication protocol interface. The communication protocol refers to the technical standard used to exchange control signals and data content with the data processing system, usually including JDBC, ODBC, Thrift, REST API or binary transmission protocol. The initialization operation also includes setting the monitoring target type (such as only monitoring query statements) and initializing operating parameters such as caching strategy and logging mechanism.

[0115] Configuring the listening proxy component's communication protocol to connect with the data processing system is a critical step in establishing a data inflow channel. This requires port mapping and message protocol adaptation based on the data processing system's interface standards. The listening proxy component uses port-level binding to attach itself to the query request entry point, typically the SQL gateway receiving layer, front-end scheduler, or middleware distribution engine. This binding operation requires the system to obtain read permissions for the access point and set listening rules for subsequent query capture operations.

[0116] Binding the listening proxy component to the query receiving port and the query parsing engine enables the system to capture both the original user-initiated request and the structured query information from the intermediate stages of the data processing system. Binding the query receiving port captures the original SQL text content, while binding the parsing engine allows observation of its parsed structure for subsequent verification and feature extraction. This binding behavior can be either passive listening mode (capturing data streams through port mirroring) or active registered listening (intercepting data stream event notifications).

[0117] Activating the continuous monitoring function of the listening proxy component means capturing incoming activity from the receiving port and the parsing engine in real time through event-driven or timed polling mechanisms. Event-driven mechanisms are often used in high-performance scenarios, triggering specific system hooks or registering callback functions to respond immediately to incoming requests. Timed polling mechanisms are suitable for interfacing with non-event interface systems, allowing you to periodically read activity records from the buffer by setting a polling period. Continuous monitoring ensures that every query operation is fully recorded and responded to promptly.

[0118] Among monitored operations, identifying query submissions and filtering non-query operations is a crucial mechanism for ensuring the system's focus on structured data extraction tasks. Query submissions typically manifest as statements such as SELECT, WITH, EXPLAIN, and SHOW in the data processing system. The system identifies the operation type through pattern recognition, syntax prefix determination, and operation type enumeration matching. It excludes update statements such as INSERT, UPDATE, and DELETE, as well as DDL statements, to avoid inadvertently capturing irrelevant operations.

[0119] Extracting query text from identified query submissions is the final step in converting monitoring behavior into structured input data. The system must extract the complete, unsplit, and unmodified original query content from the request context, including the statement body, nested structure, annotations, variable placeholders, and other content, as the basis for subsequent semantic analysis and optimization modeling. This operation requires high data accuracy and must include mechanisms such as statement boundary recognition, character escape processing, and multi-statement splitting to ensure that each extracted query statement is semantically closed and can be used independently.

[0120] This embodiment can achieve real-time monitoring and accurate capture of all query operations by monitoring the proxy component and dual binding with the receiving port and parsing engine of the data processing system, effectively avoiding missed detection and misidentification problems. This mechanism can adapt to a variety of query interfaces and execution environments, and has high concurrent monitoring capabilities and stable data acquisition accuracy. The continuous monitoring and behavior recognition mechanism ensures that the system only processes valuable query operations, improving processing efficiency while reducing invalid computing overhead. Through structured extraction of complete original query statements, the system lays a high-quality data foundation for subsequent semantic analysis, optimization recognition and performance adjustment, and realizes a full-link intelligent optimization closed loop starting from the query initiation end.

[0121] In one embodiment, the above step S20 includes:

[0122] S201, starting an execution tracer component and configuring the capture depth of the execution tracer component to be a complete execution chain;

[0123] S202, adding a unique tracking identifier to the original query statement;

[0124] S203, executing the original query statement with the unique tracking identifier attached in the data processing system;

[0125] S204, recording the execution plan operation sequence and dependency relationship of the original query statement during execution by the execution tracker component, and generating execution plan information;

[0126] S205, collecting resource usage indicators when executing the original query statement through a system monitoring interface to generate resource consumption information;

[0127] S206: Correlate the execution plan information and resource consumption information according to the unique tracking identifier to generate original execution information.

[0128] In this embodiment, starting the execution tracer component is a key step in establishing a complete execution path observation link. The component can be deployed as a query engine embedded module, a peripheral agent module, or a system debugging plug-in, and has dynamic instrumentation capabilities or log parsing capabilities. Configuring the capture depth of the component to be a complete execution link means that it should track all stages of the query from submission to completion, including semantic analysis, logical plan generation, physical plan conversion, task division, scheduling execution, and result output. The capture depth setting is usually specified through parameters and can be implemented based on the diagnostic interface provided by the system, such as calling the node structure in the plan generator or tracking the scheduler log stream.

[0129] Attaching a unique tracking identifier to the original query statement is essential for data isolation and result identification across multiple query tasks. This unique tracking identifier can be dynamically generated using a UUID generator or preset by the caller and embedded in the query context. The system must ensure that this identifier is unique within the current session or time window. This identifier must be bound to the query request structure, for example, by adding a tag to the query header or passing it to the underlying processing engine as a hidden field, ensuring that it remains visible throughout the query execution chain.

[0130] Executing original query statements with unique trace identifiers in a data processing system is a prerequisite for the system to capture true execution characteristics. The execution process must maintain consistency with the original semantics submitted by the user, and no external interference factors can affect execution behavior. Some systems support executing statements with identifiers in debug mode to generate a complete execution trace. This execution process drives the execution tracer to activate the relevant data capture process.

[0131] The execution tracer component records the execution plan operation sequence and dependency relationships of the original query statement during execution, which is a key step in obtaining information about the task execution structure. The execution plan operation sequence typically includes operator type (such as scan, filter, join, aggregation, etc.), operator order, and the relationship between logical and physical plan nodes. Dependencies reflect the data flow path and scheduling priority between operation nodes, such as the data generated by the upstream scan node is consumed by the downstream aggregation node. This information can be exported through the query optimizer's plan tree structure or generated by parsing the execution event stream in the task scheduling engine.

[0132] Resource usage metrics collected during the execution of original query statements through the system monitoring interface are used to quantify the query's resource consumption characteristics. These resource usage metrics include, but are not limited to, CPU usage, memory usage, disk I / O read / write rates, network bandwidth, and execution time. System monitoring interfaces can provide real-time statistical metrics provided by internal performance monitoring modules (such as SparkMetrics and the Flink Web UI) or external monitoring systems (such as Prometheus and Datadog). During the collection process, each metric must be associated with a unique tracking identifier to ensure data consistency and attribution.

[0133] Correlating execution plan information with resource consumption information based on unique tracking identifiers is a key step in integrating structural execution path data with numerical resource metrics into a unified analytical input. This correlation operation typically constructs a composite data structure with the identifier as the primary key. Each identifier corresponds to a set of records combining the execution path structure and resource time series data. This operation can be performed by constructing a Map structure in memory or performing query aggregation in a log system or time series database.

[0134] This embodiment uses a tracking identifier mechanism in conjunction with an execution tracker component to fully capture the query's execution plan structure and resource usage behavior within the data processing system, achieving a comprehensive record of the query execution path and resource consumption. This structured recording method supports the restoration of complex semantics and analysis of performance bottlenecks, providing a basis for subsequent optimization. Accurately correlating execution path data with resource metrics and constructing a unified dataset of raw execution information helps improve the accuracy of model training, rule generation, and dynamic adjustment processes, thereby enhancing the system's responsiveness and resource scheduling efficiency in complex query scenarios.

[0135] In one embodiment, the above step S30 includes:

[0136] S301, performing a query statement cleaning operation on the original query statement to remove comment characters and space characters to generate a cleaned query statement;

[0137] S302, performing an execution information cleaning operation on the original execution information, filtering abnormal values, and generating cleaned execution information;

[0138] S303, performing a query statement conversion operation on the cleaned query statement to generate a query vector representation;

[0139] S304, performing a normalization operation on the cleaned execution information to generate normalized execution information;

[0140] S305: Merge the query vector representation and the normalized execution information to generate preprocessed data.

[0141] In this embodiment, query cleaning is performed on the original query statement to improve the accuracy of subsequent semantic parsing and structural modeling. The cleaning process requires removing non-semantic content, such as SQL comments (e.g., content enclosed by -- and / ** / ), as well as redundant spaces or line breaks in the statement that do not affect the execution logic. This operation is typically performed using regular expression matching or syntax tree preprocessing tools to generate a compact, semantically clear cleaned query statement text, avoiding model ambiguity due to format changes.

[0142] Execution information cleansing is performed on raw execution information to eliminate extreme value interference caused by acquisition errors, abnormal scheduling, or hardware fluctuations. Execution information may contain unresolvable null values, infinite values, or statistically extreme values. These abnormal data can affect the stability and convergence of subsequent feature modeling. Cleaning operations typically include null value filling, outlier identification and removal, and data type conversion. Specific methods include threshold filtering based on statistical rules or preset upper and lower limits, thereby outputting a cleaned set of execution information that can be used for modeling.

[0143] The purpose of performing query statement conversion on the cleaned query statements is to encode the grammatical structure and logical semantics of the SQL statements into a vectorized form for processing by machine learning models. Query vector representations can be generated in a variety of ways, including sparse coding based on keyword extraction, graph neural embedding based on syntax tree structure, or context representation compression based on pre-trained models. In actual implementation, a vocabulary mapping table can be constructed to encode structural features such as SQL keywords, functions, table names, and field names into fixed-dimensional vectors, or to extract abstract syntax tree paths and convert them into graph structure features for further embedding. The goal of query vector representation is to preserve the operational structure and logical expression of the statement, so that the discrimination and generalization of query features can be achieved in subsequent models.

[0144] Normalization is performed on cleaned execution information to eliminate dimensional differences between different resource metrics and uniformly map feature values ​​to a relatively stable range. Normalization typically uses maximum-minimum scaling or Z-score standardization to convert multidimensional metrics such as CPU usage, memory usage, and I / O bandwidth into an input format with similar numerical distributions. This step improves the model's ability to perceive multidimensional features and prevents optimization results from being skewed by excessively large or small absolute values ​​of a single feature.

[0145] Merging the query vector representation and normalized execution information to generate preprocessed data with a unified structure is to build a joint feature space for model input. The merging method can adopt vector splicing, cross encoding or unified tensor construction. Different structures can be used to support different types of models, such as DNN, GNN or Transformer structures. The merging result should ensure that the semantic structure and resource features are discriminable in the unified space, while retaining the unique identification ability of each original query to facilitate tracking and feedback. As the input of the subsequent optimization model, this preprocessed data has the expression ability of both structural features and resource features, and is the basis for query optimization model training and reasoning.

[0146] This embodiment effectively removes noise, format differences, and extreme value influences through a dual cleansing and structured modeling process of both execution statements and execution behaviors, achieving input data standardization and structural compression. Unified encoding of query semantic features and resource execution features before input into the optimization model helps establish a correlation mapping between query structure and system behavior, improving the model's ability to identify query patterns and performance bottlenecks, thereby enabling more accurate and context-sensitive optimization decisions.

[0147] In one embodiment, the above step S40 includes:

[0148] S401, parsing the preprocessed data, identifying query vector representation and normalized execution information in the preprocessed data;

[0149] S402, extracting query length features and keyword distribution features from the query vector representation;

[0150] S403, extracting operation sequence features and index usage features from the normalized execution information;

[0151] S404, obtaining table structure characteristics and real-time load characteristics from the data processing system;

[0152] S405 , integrating the query length feature, keyword distribution feature, operation sequence feature, index usage feature, table structure feature and real-time load feature to generate feature information.

[0153] In this embodiment, the operation of parsing preprocessed data involves performing field-level decomposition of the structured input data to clarify the query structure information and execution behavior information contained therein. As a composite data structure composed of query statement semantic vectors and resource execution indicators, preprocessed data requires field mapping and semantic positioning during the parsing process. Through the parsing operation, data subsets of two different dimensions, namely query vector representation and normalized execution information, can be identified, providing an accurate data source foundation for subsequent feature extraction.

[0154] Extracting query length features from query vector representations primarily measures the complexity of SQL statement structures and the depth of operation hierarchies. This feature is typically constructed based on metrics such as the number of operation nodes, clause levels, nesting depth, and number of function calls in the vector, and serves as a key metric for measuring query complexity. This feature can be used to reflect the degree of redundancy in the semantic organization of SQL statements, helping to identify redundant structures or inefficient combinations that can be optimized.

[0155] Keyword distribution features characterize the types and frequency of key operation keywords in query statements, such as the distribution patterns of key operations like SELECT, JOIN, WHERE, GROUP BY, and ORDER BY. This feature reflects the structural tendencies of statement operations, such as whether aggregation is predominant and whether multiple table joins exist, thereby providing the optimizer with clues to query intent. Keyword distribution features can be extracted from vector representations using statistical methods or aggregated into structured vectors using syntax tree tags.

[0156] Extracting operation sequence features from normalized execution information is used to reconstruct the actual operation path taken by the system during query execution. This feature typically reflects the sequential structure of logical operation steps, such as the order in which operations such as scans, filters, joins, and aggregations are called, along with their dependencies. Operation sequence features can reveal key nodes, path lengths, and bottleneck locations in the query execution plan, providing a valuable reference for generating optimization strategies.

[0157] Index usage characteristics focus on whether defined indexes are hit in the current execution path, the hit rate, and the type of index used (e.g., B+ tree, bitmap index, etc.). This characteristic reflects the basic structural alignment of the statement during query tuning and is a key indicator for determining index misses, over-indexing, or redundant indexes. Index usage characteristics can be extracted by analyzing the Access Path field in the execution plan or directly parsing the Explain output field structure provided by the database system.

[0158] The purpose of acquiring table structure characteristics and real-time load characteristics from the data processing system is to introduce a wider range of system information in the current query execution context. Table structure characteristics include structural metadata such as the number of fields, data type distribution, primary key and foreign key constraints, estimated number of table rows, and whether the table is a view. This information determines the possible execution paths and resource scheduling strategies during query optimization. Real-time load characteristics include indicators reflecting the current operating environment, such as the current number of concurrent queries, system CPU and memory utilization, and disk I / O usage. Acquisition can be achieved by calling system-level statistical views, scheduler APIs, or monitoring middleware collection modules to read system status snapshots through standard interfaces.

[0159] Ultimately, the query length features, keyword distribution features, operation sequence features, index usage features, table structure features, and real-time load features are integrated to generate a unified feature information data structure. This integration can take the form of multidimensional vector concatenation, feature normalization weight reconstruction, or multi-view tensor combination, adapting to the input format requirements of subsequent models. This feature information, as a high-dimensional representation of model input, covers multiple dimensions, including query behavior, system structure, and operating environment. It possesses global expression and contextual association capabilities, providing a comprehensive basis for model optimization.

[0160] This embodiment, by constructing feature information that integrates query structure, execution behavior, system environment, and operating status, can fully capture the multi-dimensional factors that affect query performance and achieve joint modeling from semantic expression, execution path, to system resources. Compared with single-dimensional static optimization methods, this feature information structure is more context-aware and dynamically adaptable, and can provide accurate and detailed input support for subsequent optimization models, thereby improving the accuracy and adaptability of optimization suggestions. This feature extraction mechanism effectively enhances the global perception of the optimization process and reduces the risk of misjudgment in strategy generation.

[0161] In one embodiment, the above step S50 includes:

[0162] S501, converting the feature information into an input format required by the pre-trained optimization model, and inputting the converted feature information into the pre-trained optimization model;

[0163] S502, performing an inference operation in the pre-trained optimization model to generate an original model output in an encoded form;

[0164] S503, decoding the original model output in the encoded form to generate preliminary optimization operation instructions including optimized query statements, indexing strategies, or execution plan adjustments;

[0165] S504, performing database syntax verification and execution feasibility verification on the preliminary optimization operation instruction to generate a verified optimization instruction;

[0166] S505: Organize the verified optimization instructions into a structured data format to generate the optimization information.

[0167] In this embodiment, converting feature information into the input format required by the pre-trained optimization model is a necessary operation for model input interface adaptation. Feature information is usually represented as a structured tensor or multidimensional vector, but different models have specific requirements for the format, dimension order, and labeling of input data, so format normalization, field mapping, and dimension arrangement adjustment need to be performed. The conversion process may include standardization operations, one-hot encoding processing, positional encoding embedding, or graph structure expansion to ensure that the model can accurately parse various feature expressions of the input.

[0168] The converted feature information is fed into a pre-trained optimization model. This model has been trained using a large amount of historical query data, execution metrics, and optimization results, enabling it to learn the mapping between query features and performance bottlenecks. Executing inference operations involves the model performing pattern recognition and structural prediction on the input through a forward propagation path after receiving standardized feature inputs. The model ultimately outputs a set of raw model outputs representing potential optimization behaviors. These are typically encoded sequences or vector structures that possess operational semantics but lack a concrete form that can be directly executed.

[0169] Decoding the original model output involves mapping the model output from the encoding space back to the query language's operational semantic space. This decoding process, based on the model's output encoding rules, gradually restores the structured query statement, indexing strategy recommendations, or execution plan adjustment suggestions. Optimized query statements may include restructuring, subquery replacement, or predicate rearrangement. Indexing strategies may include creating new indexes, modifying the order of index fields, or suggesting index merges. Execution plan adjustments may involve changing the join order, setting parallel execution flags, or adjusting hint annotations. Ultimately, a preliminary set of optimization instructions is formed.

[0170] Performing database syntax verification and execution feasibility verification on preliminary optimization operation instructions is a key step in ensuring the executable nature of optimization suggestions. Syntax verification refers to using the syntax rule verification module of the target database system to determine whether the generated instructions comply with the database language specifications, such as whether there are syntax conflicts, field errors, or illegal expressions. Execution feasibility verification evaluates whether the optimization instructions can be successfully executed in the current data processing system by estimating query costs, analyzing data access paths, simulating index hits, and performing preliminary screening for potential resource exhaustion or performance regression risks. These two types of verification can filter out low-quality output introduced by imprecise expressions or context mismatches during model generation.

[0171] Finally, the validated optimization instructions are organized into a structured data format, generating a unified optimization information output. This structured format can be expressed in JSON, Protocol Buffers, or an intermediate representation syntax tree structure defined by the database system. It includes metadata such as the optimization goal (e.g., execution time reduction), recommended actions (e.g., adding an index), and the scope of impact (e.g., affected tables or fields). This structured optimization information can be directly input into the optimization execution engine for the next step or manually applied to the database query environment by the user for review.

[0172] This embodiment uses a pre-trained optimization model to infer and generate multidimensional feature information containing semantics, behavior, and system status, enabling rapid identification of query bottlenecks and automatic generation of optimization suggestions without human intervention. This mechanism overcomes the traditional optimization process's reliance on manual experience and grammatical templates, maintaining high accuracy and strong generalization capabilities in complex and dynamic query environments. Structured optimization information not only improves the comprehensibility and executability of suggestions, but also provides a good interface standard for subsequent system integration and scheduling, significantly improving the automation level and application flexibility of database query optimization.

[0173] In one embodiment, the above step S60 includes:

[0174] S601, parsing the optimization information, identifying the optimization operation type contained in the optimization information, and extracting specific adjustment parameters corresponding to the optimization operation type from the optimization information;

[0175] S602: If the optimization operation type is query statement text modification, rewrite the grammatical structure or clauses of the original query statement according to the rewriting strategy or target text in the specific adjustment parameters to generate a rewritten query statement;

[0176] S603: If the optimization operation type is execution mode adjustment, then according to the optimizer hint or execution configuration in the specific adjustment parameter, corresponding hint information is embedded in the original query statement or the execution environment parameters of the original query statement are configured to generate a configured query statement;

[0177] S604: Use the rewritten query statement and / or the configured query statement as the optimized query instruction.

[0178] In this embodiment, the operation of parsing optimization information is a process of semantic recognition and field analysis of structured optimization suggestions, which aims to clarify the optimization goals and their implementation paths. The optimization information usually contains a set of optimization operation type identifiers corresponding to performance bottlenecks, such as "rewrite query statements", "inject optimizer hints", "adjust execution parameters", etc. Specific parameter configurations are nested under each type, including field reordering strategies, index hint keywords, connection method preferences, concurrency limit parameters, etc. The system uses a logical judgment structure analyzer to extract and classify the structural labels of each type of optimization operation, and then determines the subsequent adjustment method.

[0179] When the optimization operation type is identified as query statement text modification, the adjustment behavior revolves around the logical structure of the original query statement. The rewriting strategy here comes from the statement replacement template, predicate merging instructions, subquery expansion suggestions, or UNION to JOIN strategy prompts embedded in the optimization information. During execution, the system will reconstruct the FROM, WHERE, GROUP BY and other clause structures of the original statement based on these strategies, which may involve logical expression rearrangement, predicate extraction, or connection path reconstruction to generate a rewritten query statement that meets the premise of semantic preservation. This rewriting process requires relying on the structural parsing engine to decompose and reconstruct the abstract syntax tree (AST) of the SQL statement to ensure that the generated result has better execution characteristics under semantic equivalence.

[0180] If the optimization operation type is identified as an execution mode adjustment, this type of operation does not directly change the semantic structure of the query text. Instead, it intervenes in the execution path by embedding hints or adjusting runtime parameters. Optimizer hints are typically manifested in the form of explicit tags such as / *+INDEX(table column) / , / +USE_HASH(table) / , and / +PARALLEL(tableN)* / in the statement. These hints guide the query optimizer to prioritize a certain execution strategy. Execution environment parameters include the number of concurrent threads, memory limits, and temporary tablespace configurations. These parameters are attached to the query task scheduling module through connection configuration or context injection mechanisms. The adjustment results are encapsulated as a configured query statement, which may not structurally change the original statement content but comes with new execution context or scheduling properties.

[0181] Ultimately, the system outputs the rewritten and / or configured query statements as optimized query instructions. These instructions can be directly fed into the execution plan generation module or executed in the target database through the policy scheduler. This dual-branch processing mechanism (structural rewriting and execution configuration) ensures the completeness and adaptability of the optimization instructions, and also facilitates adaptation to the varying semantic adjustments and performance control requirements of various database environments.

[0182] Example: In financial services, risk control systems frequently execute complex SQL queries to conduct anti-fraud analysis on large-value transaction records and assess transaction time distribution and abnormal account behavior patterns. Deployed on a distributed data processing platform, this system involves numerous JOINs, nested subqueries, and index accesses, making manual optimization extremely challenging. In this scenario, a data monitoring module is first configured within the data processing platform. This module is bound to the SQL gateway's receiving port and query parsing engine through a configured communication protocol. Once activated, the monitoring agent component continuously monitors transaction log query activity and captures raw query statements when it detects triggers for typical risk model assessment tasks, such as risky transaction screening SQL statements involving multi-table joins and subqueries. The logging module then activates the execution tracker component and appends a unique tracking identifier to ensure the integrity of the execution trace. During query execution, the system collects execution plan information, records the scan path, join order, and index call information, and simultaneously collects resource consumption metrics such as CPU usage, I / O times, and response time. Next, the captured raw query statements and corresponding raw execution information are preprocessed. This process removes comments and standardizes SQL statements, converting them into vector representations. It also normalizes execution information, filters out anomalies, and forms a standardized numerical set, ultimately producing preprocessed data with a unified structure. The system extracts feature information from the preprocessed data, including query keyword density, statement length, operation sequence complexity, and index coverage. It also supplements the financial transaction table structure and current load information from the current system state, fusing them together to form a complete feature vector. These features are fed into a pretrained optimization model, which performs inference to generate preliminary optimization results in encoded form. The decoder then generates optimization instructions, such as modifying the JOIN order, adding filter predicates, or replacing nested loops with HASH JOINs. The optimization instructions are then validated against SQL syntax and database execution constraints, eliminating invalid strategies and outputting them in a structured format. Based on this final optimization information, the system adjusts the original SQL statement: if semantic rewriting is required, subquery structures are replaced and logical expressions are rewritten; if execution method adjustments are required, prompt instructions such as / *+INDEX(RISK_TABLE IDX_A)* / are embedded. The new SQL statements finally outputted can perform risk assessment tasks more efficiently, shortening the response time from 45 seconds to 12 seconds.

[0183] In the healthcare business scenario, the hospital operations platform needs to analyze registration records and visit frequency data daily to generate resource allocation reports and disease category trend forecasts. The query logic is complex, involving multiple data tables such as medical records, physician schedules, and disease categories. Original queries often execute slowly due to missing indexes or improper join sequences. During the deployment phase, a data monitoring module connects to the hospital database platform via embedded middleware to monitor physician registration queries and visit statistics. The monitoring module successfully captures queries such as "Statistics of high-frequency registrations by department over the past seven days" and saves them as the original query. Before executing this SQL, the recording module activates the execution tracer, attaches a unique tracking identifier, and records the query plan throughout the entire process, including full table scans, temporary table generation, and ORDER BY usage. It also collects metrics such as CPU load, lock waits, and execution time to generate raw execution information. The preprocessing module normalizes the captured SQL, converts it into a vector representation, and cleans up abnormal resource records. The query representation and normalized performance data are combined to form unified preprocessed data, providing standard input for subsequent feature extraction. The system identifies query structure and execution features from preprocessed data and simultaneously extracts the registration form structure, index status of the disease tag table, and current data load from the hospital's HIS system. The resulting fused feature set includes keyword density, JOIN path depth, index hit rate, and table join fan-out factor. After receiving these features, the optimization module uses a pretrained model to infer and generate optimization actions. These include adjusting index usage (recommending the use of composite indexes), rewriting the FROM clause join order, and embedding parallel prompts. These suggestions are then validated for syntax and feasibility before outputting the final optimization information. Based on the optimization information, the system determines the operation type. If a statement rewrite is recommended, the JOIN structure is rearranged and redundant logical expressions are simplified. If parameter optimization is indicated, database optimizer prompts such as / *+PARALLEL(REGISTER_INFO 4)* / are embedded. The resulting optimized SQL reduces the execution time of a disease statistics task from 20 seconds to less than 6 seconds, improving operational analysis efficiency and reducing system congestion.

[0184] This embodiment can accurately match the bottleneck position of the original query statement at the structural and execution levels by mapping the structured suggestions extracted from the optimization information into specific query statement reconstruction actions and execution parameter adjustment actions. Statement-level rewriting improves the optimization potential of the execution plan, while the adjustment of the execution method provides control over resource scheduling and optimizer strategies, thereby achieving full-link optimization output from semantic logic to underlying execution. This layered processing method ensures that the optimization suggestions are not only theoretically feasible, but can also be directly adopted and implemented in the target system, greatly improving the automation and accuracy of optimization execution.

[0185] In one embodiment, a device for intelligently optimizing query statements is provided, and the device for intelligently optimizing query statements corresponds one-to-one to the method for intelligently optimizing query statements in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the intelligent query optimization device of the present invention. It includes a query monitoring module 10, an execution tracking module 20, a data preprocessing module 30, a feature extraction module 40, an optimization reasoning module 50, and a query rewriting module 60. Each functional module is described in detail below:

[0186] A query monitoring module 10 is used to monitor the operation behavior of the data processing system using a data monitoring module and capture the original query statement through the data monitoring module;

[0187] An execution tracking module 20 is configured to record execution plan information and resource consumption information of the original query statement in the data processing system, and generate original execution information based on the execution plan information and resource consumption information;

[0188] A data preprocessing module 30 is used to preprocess the original query statement and the original execution information to generate preprocessed data;

[0189] A feature extraction module 40 is used to extract feature information from the preprocessed data;

[0190] An optimization reasoning module 50 is configured to generate optimization information based on the feature information using a pre-trained optimization model;

[0191] The query rewriting module 60 is configured to adjust the content or execution mode of the original query statement according to the optimization information, and generate an optimized query instruction according to the adjusted content or execution mode.

[0192] In one embodiment, the query monitoring module 10 is specifically configured to:

[0193] Initializing the monitoring proxy component and configuring the communication protocol of the monitoring proxy component so that it can interface with the data processing system;

[0194] Binding the listening proxy component to a query receiving port and a query parsing engine of a data processing system;

[0195] Activate the continuous monitoring function of the listening agent component to continuously scan the bound query receiving port and the operation behavior of the query parsing engine;

[0196] Identify query submission behaviors from monitored operations and filter out non-query operations;

[0197] The complete query statement text is captured from the identified query submission behavior as the original query statement.

[0198] In one embodiment, the execution tracking module 20 is specifically configured to:

[0199] Starting an execution tracer component and configuring the capture depth of the execution tracer component to be a complete execution chain;

[0200] appending a unique tracking identifier to the original query statement;

[0201] executing the original query statement appended with the unique tracking identifier in the data processing system;

[0202] Recording the execution plan operation sequence and dependency relationship of the original query statement during execution through the execution tracker component to generate execution plan information;

[0203] Collect resource usage indicators when executing the original query statement through the system monitoring interface to generate resource consumption information;

[0204] The execution plan information and resource consumption information are associated with each other according to the unique tracking identifier to generate original execution information.

[0205] In one embodiment, the data preprocessing module 30 is specifically configured to:

[0206] Performing a query statement cleaning operation on the original query statement to remove comment characters and space characters to generate a cleaned query statement;

[0207] Performing an execution information cleaning operation on the original execution information, filtering abnormal values, and generating cleaned execution information;

[0208] Performing a query statement conversion operation on the cleaned query statement to generate a query vector representation;

[0209] performing a normalization operation on the cleaned execution information to generate normalized execution information;

[0210] The query vector representation and the normalized execution information are combined to generate preprocessed data.

[0211] In one embodiment, the feature extraction module 40 is specifically configured to:

[0212] parsing the preprocessed data to identify query vector representations and normalized execution information in the preprocessed data;

[0213] extracting query length features and keyword distribution features from the query vector representation;

[0214] extracting operation sequence features and index usage features from the normalized execution information;

[0215] Obtain table structure characteristics and real-time load characteristics from the data processing system;

[0216] The query length feature, keyword distribution feature, operation sequence feature, index usage feature, table structure feature and real-time load feature are integrated to generate feature information.

[0217] In one embodiment, the optimization reasoning module 50 is specifically configured to:

[0218] Converting the feature information into an input format required by the pre-trained optimization model, and inputting the converted feature information into the pre-trained optimization model;

[0219] performing inference operations on the pre-trained optimized model to generate raw model outputs in encoded form;

[0220] Decoding the original model output in the encoded form to generate preliminary optimization operation instructions including optimized query statements, indexing strategies, or execution plan adjustments;

[0221] Performing database syntax verification and execution feasibility verification on the preliminary optimization operation instructions to generate verified optimization instructions;

[0222] The verified optimization instructions are organized into a structured data format to generate the optimization information.

[0223] In one embodiment, the query rewriting module 60 is specifically configured to:

[0224] parsing the optimization information, identifying the optimization operation type contained in the optimization information, and extracting specific adjustment parameters corresponding to the optimization operation type from the optimization information;

[0225] If the optimization operation type is query statement text modification, rewriting the grammatical structure or clauses of the original query statement according to the rewriting strategy or target text in the specific adjustment parameters to generate a rewritten query statement;

[0226] If the optimization operation type is execution mode adjustment, then according to the optimizer prompt or execution configuration in the specific adjustment parameter, the corresponding prompt information is embedded in the original query statement or the execution environment parameters of the original query statement are configured to generate a configured query statement;

[0227] The rewritten query statement and / or the configured query statement is used as the optimized query instruction.

[0228] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide determination and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps of the server side of an intelligent optimization method for query statements.

[0229] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide determination and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of an intelligent optimization method for query statements.

[0230] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0231] Using a data monitoring module to monitor the operation behavior of the data processing system, and capturing the original query statement through the data monitoring module;

[0232] Recording execution plan information and resource consumption information of the original query statement in the data processing system, and generating original execution information based on the execution plan information and resource consumption information;

[0233] Preprocessing the original query statement and the original execution information to generate preprocessed data;

[0234] extracting feature information from the preprocessed data;

[0235] Based on the feature information, generating optimization information through a pre-trained optimization model;

[0236] The content or execution mode of the original query statement is adjusted according to the optimization information, and an optimized query instruction is generated according to the adjusted content or execution mode.

[0237] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0238] Using a data monitoring module to monitor the operation behavior of the data processing system, and capturing the original query statement through the data monitoring module;

[0239] Recording execution plan information and resource consumption information of the original query statement in the data processing system, and generating original execution information based on the execution plan information and resource consumption information;

[0240] Preprocessing the original query statement and the original execution information to generate preprocessed data;

[0241] extracting feature information from the preprocessed data;

[0242] Based on the feature information, generating optimization information through a pre-trained optimization model;

[0243] The content or execution mode of the original query statement is adjusted according to the optimization information, and an optimized query instruction is generated according to the adjusted content or execution mode.

[0244] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0245] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0246] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0247] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. An intelligent optimization method for query statements, characterized in that: The following steps are involved: Using a data monitoring module to monitor the operation behavior of the data processing system, and capturing the original query statement through the data monitoring module; Recording execution plan information and resource consumption information of the original query statement in the data processing system, and generating original execution information based on the execution plan information and resource consumption information; Preprocessing the original query statement and the original execution information to generate preprocessed data; extracting feature information from the preprocessed data; Based on the feature information, generating optimization information through a pre-trained optimization model; The content or execution mode of the original query statement is adjusted according to the optimization information, and an optimized query instruction is generated according to the adjusted content or execution mode.

2. The intelligent optimization method for query statements according to claim 1, characterized in that: Using a data monitoring module to monitor the operational behavior of the data processing system and capturing the original query statement through the data monitoring module includes: Initializing the monitoring proxy component and configuring the communication protocol of the monitoring proxy component so that it can interface with the data processing system; Binding the listening proxy component to a query receiving port and a query parsing engine of a data processing system; Activate the continuous monitoring function of the listening agent component to continuously scan the bound query receiving port and the operation behavior of the query parsing engine; Identify query submission behaviors from monitored operations and filter out non-query operations; The complete query statement text is captured from the identified query submission behavior as the original query statement.

3. The intelligent optimization method for query statements according to claim 1, characterized in that: Recording execution plan information and resource consumption information of the original query statement in the data processing system, and generating original execution information based on the execution plan information and resource consumption information, including: Starting an execution tracer component and configuring the capture depth of the execution tracer component to be a complete execution chain; appending a unique tracking identifier to the original query statement; executing the original query statement appended with the unique tracking identifier in the data processing system; Recording the execution plan operation sequence and dependency relationship of the original query statement during execution through the execution tracker component to generate execution plan information; Collect resource usage indicators when executing the original query statement through the system monitoring interface to generate resource consumption information; The execution plan information and resource consumption information are associated with each other according to the unique tracking identifier to generate original execution information.

4. The intelligent optimization method for query statements according to claim 1, wherein: Preprocessing the original query statement and the original execution information to generate preprocessed data includes: Performing a query statement cleaning operation on the original query statement to remove comment characters and space characters to generate a cleaned query statement; Performing an execution information cleaning operation on the original execution information, filtering abnormal values, and generating cleaned execution information; Performing a query statement conversion operation on the cleaned query statement to generate a query vector representation; performing a normalization operation on the cleaned execution information to generate normalized execution information; The query vector representation and the normalized execution information are combined to generate preprocessed data.

5. The intelligent optimization method for query statements according to claim 1, wherein: Extracting feature information from the preprocessed data includes: parsing the preprocessed data to identify query vector representations and normalized execution information in the preprocessed data; extracting query length features and keyword distribution features from the query vector representation; extracting operation sequence features and index usage features from the normalized execution information; Obtain table structure characteristics and real-time load characteristics from the data processing system; The query length feature, keyword distribution feature, operation sequence feature, index usage feature, table structure feature and real-time load feature are integrated to generate feature information.

6. The intelligent optimization method for query statements according to claim 1, wherein: Based on the feature information, optimization information is generated by a pre-trained optimization model, including: Converting the feature information into an input format required by the pre-trained optimization model, and inputting the converted feature information into the pre-trained optimization model; performing inference operations on the pre-trained optimized model to generate raw model outputs in encoded form; Decoding the original model output in the encoded form to generate preliminary optimization operation instructions including optimized query statements, indexing strategies, or execution plan adjustments; Performing database syntax verification and execution feasibility verification on the preliminary optimization operation instructions to generate verified optimization instructions; The verified optimization instructions are organized into a structured data format to generate the optimization information.

7. The intelligent optimization method for query statements according to claim 1, characterized in that: Adjusting the content or execution mode of the original query statement according to the optimization information, and generating an optimized query instruction according to the adjusted content or execution mode, including: parsing the optimization information, identifying the optimization operation type contained in the optimization information, and extracting specific adjustment parameters corresponding to the optimization operation type from the optimization information; If the optimization operation type is query statement text modification, rewriting the grammatical structure or clauses of the original query statement according to the rewriting strategy or target text in the specific adjustment parameters to generate a rewritten query statement; If the optimization operation type is execution mode adjustment, then according to the optimizer prompt or execution configuration in the specific adjustment parameter, the corresponding prompt information is embedded in the original query statement or the execution environment parameters of the original query statement are configured to generate a configured query statement; The rewritten query statement and / or the configured query statement is used as the optimized query instruction.

8. An intelligent optimization device for query statements, characterized in that: The intelligent optimization device for query statements includes: A query monitoring module, configured to monitor the operation behavior of the data processing system using the data monitoring module and capture the original query statement through the data monitoring module; an execution tracking module, configured to record execution plan information and resource consumption information of the original query statement in the data processing system, and generate original execution information based on the execution plan information and resource consumption information; A data preprocessing module, configured to preprocess the original query statement and the original execution information to generate preprocessed data; A feature extraction module, configured to extract feature information from the preprocessed data; An optimization reasoning module, configured to generate optimization information based on the feature information through a pre-trained optimization model; The query rewriting module is used to adjust the content or execution mode of the original query statement according to the optimization information, and generate an optimized query instruction according to the adjusted content or execution mode.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and an intelligent optimization program for query statements stored in the memory and capable of running on the processor. When the intelligent optimization program for query statements is executed by the processor, the steps of the intelligent optimization method for query statements according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores an intelligent optimization program for query statements, and when the intelligent optimization program for query statements is executed by a processor, the steps of the intelligent optimization method for query statements according to any one of claims 1 to 7 are implemented.

Images