Kernel rag-based database intelligent operation and maintenance method, device and equipment and medium

Abstract

The application relates to the technical field of database operation and maintenance, and discloses a database intelligent operation and maintenance method and device based on a kernel RAG, equipment and a medium, which comprises the following steps: splicing multiple source heterogeneous data to generate a knowledge text, encoding the knowledge text to obtain a knowledge text vector, and constructing a vector index according to the knowledge text vector; intercepting an SQL request through a RAG retrieval interceptor, splicing the current statistical information summary and historical execution fingerprints, and constructing a multi-dimensional retrieval query; performing multi-path recall in parallel by using the vector index, inputting the multi-path recall result into a cross encoder after being combined, and performing deep interactive coding, and screening out historical experience knowledge items according to the deep interactive coding result; converting the historical experience knowledge items into RAG optimizer hints, injecting the RAG optimizer hints into a physical execution plan selector, and executing the physical execution plan according to a preset priority strategy; and performing closed-loop updating on the database according to feedback index data. The application improves operation and maintenance efficiency and execution performance.

Description

Technical Field

[0001] This invention relates to the field of database operation and maintenance technology, and in particular to a database intelligent operation and maintenance method, apparatus, equipment and medium based on kernel RAG. Background Technology

[0002] Traditional database operations and maintenance heavily rely on the personal experience and technical expertise of database administrators (DBAs), especially in large enterprises such as finance and telecommunications. DBAs often need to manage dozens or even hundreds of database instances simultaneously, and their daily work covers multiple dimensions, including performance tuning, fault diagnosis, capacity planning, and security auditing. Research data shows that the average processing time for a single major performance failure in a typical bank's core transaction system can reach 2 to 6 hours, with approximately 60% to 70% of that time spent on problem localization and root cause analysis. DBAs' operational knowledge primarily comes from operational documents, ticketing systems, and various database logs (such as slow logs and error logs).

[0003] To alleviate the burden on manual labor, the industry has developed various auxiliary tools. Rule-based expert systems (such as Oracle Enterprise Manager) use predefined rule bases to achieve fault detection and alarms. Their advantages are strong interpretability and low false alarm rate, but the rule coverage is limited and cannot cover unknown fault modes, and the maintenance cost increases linearly with the system size. Performance analysis tools based on statistical learning (such as Percona PMM and Datadog) collect runtime metrics and use statistical models to detect anomalies, which can effectively discover performance degradation that has occurred, but they lack forward-looking optimization capabilities and cannot provide specific remediation solutions. Traditional external RAG systems (such as PgAI, DBA-GPT, and Huawei Cloud GaussDB intelligent operation and maintenance) combine large language models with external databases to provide natural language question-and-answer interaction, but these systems are all deployed outside the database and access kernel information through API calls, resulting in problems such as high retrieval latency and context fragmentation. Optimization tools based on execution plan analysis (such as Tencent Blue Whale and Alibaba Cloud DAS) can parse execution plans and generate optimization suggestions, but still require manual intervention for implementation, failing to completely free up DBAs.

[0004] A deeper contradiction lies in the disconnect between knowledge and execution context. Existing RAG solutions are all deployed outside the database, meaning search results cannot be applied to the kernel's execution plan selection logic. This lack of awareness of the SQL execution context leads to low recommendation relevance. Simultaneously, the database relies on manual input, resulting in a disconnect from the actual database operation and an inability to automatically associate SQL patterns. This leads to delayed updates and high maintenance costs. More importantly, external searches only provide textual suggestions, which cannot be automatically converted into execution plan adjustments. DBAs still need to manually add hints, increasing operational risks and raising the barrier to entry. Furthermore, the network latency (10-100 milliseconds), data migration, and serialization overhead introduced by independent vector databases further increase system resource consumption. The entire system lacks a closed-loop self-evolution mechanism, failing to automatically learn from actual DBA optimization operations. Knowledge quality degrades over time, conflict resolution strategies are lacking, and contradictions between knowledge from multiple sources are difficult to resolve effectively. Ultimately, slow SQL optimization still relies on manual analysis by DBAs, taking an average of 2 to 4 hours, with results varying depending on individual experience. The retrieval process is not linked to SQL compilation and execution plan selection, and historical experience cannot be directly applied to plan optimization. The accuracy of retrieval depends solely on text similarity, ignoring the execution context, resulting in low overall optimization efficiency and failing to achieve true kernel-level intelligent operation and maintenance. Summary of the Invention

[0005] The main objective of this invention is to provide a database intelligent operation and maintenance method, device, equipment, and storage medium based on kernel RAG, aiming to solve the technical problems in the prior art where database intelligent operation and maintenance lacks kernel-level knowledge retrieval and automatic optimization capabilities, resulting in low operation and maintenance efficiency, fragmented knowledge, and inability to achieve closed-loop evolution.

[0006] To achieve the above objectives, this invention provides a database intelligent operation and maintenance method based on kernel RAG, comprising: Collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text; The knowledge text is vector-encoded to obtain a knowledge text vector, and a vector index is constructed based on the knowledge text vector. The SQL request is intercepted by the RAG retrieval interceptor. The SQL text in the SQL request is normalized. The normalized SQL text is then concatenated with the current statistical information summary and the historical execution fingerprint to construct a multi-dimensional retrieval query. Based on the multidimensional retrieval query, the vector index is used to perform multi-way recall of vector retrieval, full-text retrieval and strategy matching in parallel. The multi-way recall results are merged and input into the cross encoder for deep interactive encoding. Historical experience knowledge items are then selected based on the deep interactive encoding results. The historical experience knowledge items are converted into RAG optimizer hints, and the RAG optimizer hints are injected into the physical execution plan selector to execute the physical execution plan according to the preset priority strategy; Collect feedback indicator data after executing the physical execution plan, and perform closed-loop updates to the database based on the feedback indicator data.

[0007] Furthermore, to achieve the above objectives, the present invention provides a database intelligent operation and maintenance device based on kernel RAG, comprising: The knowledge text generation module is used to collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text. The vector index construction module is used to perform vector encoding on the knowledge text to obtain a knowledge text vector, and to construct a vector index based on the knowledge text vector. The multidimensional retrieval construction module is used to intercept SQL requests through the RAG retrieval interceptor, normalize the SQL text in the SQL request, and concatenate the normalized SQL text with the current statistical information summary and historical execution fingerprint to construct a multidimensional retrieval query. The multi-path recall module is used to perform multi-path recall, vector retrieval, full-text retrieval and strategy matching in parallel using the vector index based on the multi-dimensional retrieval query. The multi-path recall results are merged and input into the cross encoder for deep interactive encoding. Historical experience knowledge items are then selected based on the deep interactive encoding results. The hint injection module is used to convert the historical experience knowledge items into RAG optimizer hints and inject the RAG optimizer hints into the physical execution plan selector to execute the physical execution plan according to a preset priority strategy. The feedback closed-loop update module is used to collect feedback indicator data after executing the physical execution plan, and to perform closed-loop updates to the database based on the feedback indicator data.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a kernel RAG-based intelligent database operation and maintenance program stored in the memory and executable on the processor, wherein when the kernel RAG-based intelligent database operation and maintenance program is executed by the processor, it implements the steps of the kernel RAG-based intelligent database operation and maintenance method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a database intelligent operation and maintenance program based on kernel RAG, wherein when the kernel RAG-based database intelligent operation and maintenance program is executed by a processor, it implements the steps of the kernel RAG-based database intelligent operation and maintenance method described above.

[0010] Beneficial Effects: This invention relates to the field of database operation and maintenance technology, and discloses a database intelligent operation and maintenance method, device, equipment, and medium based on kernel RAG, including: collecting multi-source heterogeneous data, preprocessing the multi-source heterogeneous data, concatenating the preprocessed multi-source heterogeneous data to generate knowledge text; performing vector encoding on the knowledge text to obtain knowledge text vectors, and constructing a vector index based on the knowledge text vectors; intercepting SQL requests through a RAG retrieval interceptor, normalizing the SQL text in the SQL requests, and comparing the normalized SQL text with the current statistical information summary and historical execution index. The text is structured by concatenating patterns to construct a multi-dimensional retrieval query. Based on this query, vector retrieval, full-text retrieval, and strategy matching are executed in parallel using the vector index for multi-path recall. The multi-path recall results are merged and input into a cross-encoder for deep interactive encoding. Historical experience knowledge items are then selected based on the deep interactive encoding results. These historical experience knowledge items are converted into RAG optimizer hints and injected into the physical execution plan selector. The physical execution plan is then executed according to a preset priority strategy. Feedback metrics data after executing the physical execution plan are collected, and the database is updated in a closed loop based on these feedback metrics data. This invention achieves automatic collection, real-time retrieval, and execution plan injection of operational knowledge through a kernel-level RAG architecture. This helps DBAs automatically optimize slow SQL queries and accumulate experience in a closed loop, significantly improving the intelligence level and performance tuning efficiency of database operations and maintenance. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a database intelligent operation and maintenance method based on kernel RAG in one embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the database intelligent operation and maintenance method based on kernel RAG of the present invention. Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the database intelligent operation and maintenance device based on kernel RAG of the present invention. Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The database intelligent operation and maintenance method based on kernel RAG provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can collect multi-source heterogeneous data from the client, preprocess the data, and concatenate the preprocessed data to generate knowledge text. The knowledge text is then vector-encoded to obtain knowledge text vectors, and a vector index is constructed based on these vectors. SQL requests are intercepted using a RAG retrieval interceptor, and the SQL text in the requests is normalized. The normalized SQL text is then concatenated with the current statistical information summary and historical execution fingerprints to construct a multi-dimensional retrieval query. Based on this multi-dimensional retrieval query, the vector index is used to execute vector retrieval, full-text retrieval, and strategy matching in parallel for multi-path recall. The multi-path recall results are merged and input into a cross-encoder for deep interactive encoding. Historical experience knowledge items are then filtered based on the deep interactive encoding results. These historical experience knowledge items are converted into RAG optimizer hints and injected into a physical execution plan selector. The physical execution plan is executed according to a preset priority strategy. Feedback indicator data after executing the physical execution plan is collected, and the database is updated in a closed loop based on this feedback indicator data. This invention utilizes a kernel-level RAG architecture to automatically collect, retrieve, and inject operational knowledge in real time, helping DBAs automatically optimize slow SQL queries and accumulate experience in a closed loop, significantly improving the intelligence level and performance tuning efficiency of database operations and maintenance. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the database intelligent operation and maintenance method based on kernel RAG provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] This invention constructs a five-layer end-to-end architecture within the database kernel: application interaction layer → knowledge management service layer → retrieval enhancement generation layer → kernel vector index layer → kernel storage integration layer. Application Interaction Layer: Responsible for interacting with database administrators (DBAs), providing visual displays of optimization suggestions, collecting interaction behavior (adoption / correction / rejection), and presenting feedback on optimization results.

[0016] Knowledge Management Service Layer: Responsible for the collection, preprocessing, and standardized assembly of multi-source heterogeneous data, as well as version management of knowledge texts, calculation of Knowledge Quality Score (KQS), and detection and resolution of knowledge conflicts.

[0017] The retrieval enhancement generation layer is responsible for triggering the RAG retrieval interceptor during SQL compilation, constructing multidimensional retrieval queries, and performing three-way recall in parallel: vector retrieval, full-text retrieval (BM25), and strategy matching (SQL Pattern regularization). It also performs deep interactive encoding and reordering through the BERT cross encoder.

[0018] Kernel Vector Index Layer: Responsible for calling the vector encoding model (BGE / text2vec-chinese) to encode knowledge text into 1024-dimensional vectors, constructing vector indexes using the Hierarchical Navigable Small World (HNSW) algorithm, accelerating vector distance calculations using the SIMD instruction set (AVX2), and managing retrieval results through multi-level caching (L1 / L2 / L3).

[0019] Kernel Storage Integration Layer: Responsible for persisting vector indexes to the shared storage of data nodes through the database write-ahead log (WAL) mechanism, reusing the transaction, backup, and recovery capabilities of the database kernel to achieve zero-data migration deployment.

[0020] like Figure 2 As shown, the intelligent database operation and maintenance method based on kernel RAG proposed in this invention includes the following steps: S100. Collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text. S200. The knowledge text is vector-encoded to obtain a knowledge text vector, and a vector index is constructed based on the knowledge text vector. S300. Intercept SQL requests through the RAG retrieval interceptor, normalize the SQL text in the SQL request, and concatenate the normalized SQL text with the current statistical information summary and historical execution fingerprint to construct a multi-dimensional retrieval query. S400. Based on the multidimensional retrieval query, the vector index is used to perform multi-way recall of vector retrieval, full-text retrieval and strategy matching in parallel. The multi-way recall results are merged and input into the cross encoder for deep interactive encoding. Historical experience knowledge items are selected according to the deep interactive encoding results. S500: Convert the historical experience knowledge items into RAG optimizer hints, inject the RAG optimizer hints into the physical execution plan selector, and execute the physical execution plan according to the preset priority strategy; S600: Collect feedback indicator data after executing the physical execution plan, and perform closed-loop update of the database based on the feedback indicator data.

[0021] In this embodiment, the system first collects heterogeneous data from multiple data sources. These data sources include slow query SQL texts exceeding a preset threshold (default 1 second) and their execution plans (operator sequences obtained via the EXPLAIN command); various alarm events during database operation and their root causes and remedial measures; and experience documents accumulated by the database administrator (DBA). The collected raw data then enters the preprocessing stage, where the system cleans, formats, and performs structured parsing, such as extracting key information like join order, index usage, operator type, and parallelism from the execution plan. After preprocessing, the system concatenates the heterogeneous data from multiple sources according to a unified format to generate structured knowledge text, preparing for subsequent vectorization.

[0022] The system invokes a large vector model (such as BGE or the text2vec-chinese model) to encode the generated knowledge text into a 1024-dimensional vector representation. After vectorization, the system employs a Hierarchical Navigable Small World (HNSW) algorithm to construct an efficient vector index. This index organizes vector data through a multi-layered graph structure, precisely locating from the top layer downwards during searches, achieving near-nearest neighbor search with logarithmic time complexity. The vector index is deployed on the database's Coordinator Node (CN), sharing storage resources with the kernel to achieve zero data migration. Simultaneously, the system utilizes Single Instruction Multiple Data (SIMD) instruction sets (such as AVX2) to accelerate vector computation, improving core computing performance by 8 to 16 times.

[0023] When an SQL request enters the database kernel, the system first performs standard SQL parsing, generating a parse tree and a logical execution plan. At the compile-time node between the generation of the logical execution plan and the selection of the physical execution plan, the RAG interceptor is triggered. The interceptor normalizes the SQL text, removing specific constant values ​​from the SQL statement while retaining its structural skeleton, generating a unique identifier for the SQL template. Subsequently, the system concatenates the normalized SQL text, the current database statistics summary, and the historical execution fingerprint to construct a multi-dimensional retrieval query, ensuring that the retrieval results are highly adapted to the execution context of the current SQL.

[0024] Based on the constructed multidimensional retrieval query, the system executes a three-way recall strategy in parallel: the vector retrieval channel uses the HNSW index for Top-K similarity retrieval; the keyword retrieval channel uses the Best Matching 25 (BM25) full-text retrieval algorithm for relevance scoring; and the rule matching channel uses SQL Pattern regular expressions for precise matching. The results of the three recalls are merged and input into the BERT cross-encoder for deep interactive encoding and re-ranking. The cross-encoder uses the query and candidate documents as a pair of inputs for joint encoding, capturing complex interaction relationships at the token level and outputting a more accurate relevance score. Finally, the system selects the top-ranked historical experience knowledge items.

[0025] The system automatically converts selected historical knowledge items into database optimizer hints (OptimizerHints, or Hints for short). Hints can specify key parameters such as join order, index selection, parallelism, join method, and partition pruning. After conversion, the system injects the generated Hints into the physical execution plan selector, adjusting the physical operators in conjunction with the Hint instructions and cost model to generate the final execution plan. The entire process follows a preset priority strategy: Hints manually added by the DBA have the highest priority, followed by Hints generated by RAG inference, and the database default optimizer strategy has the lowest priority.

[0026] After the physical execution plan is completed, the system collects execution feedback metrics, including actual execution time and resource consumption. Based on this feedback, the system initiates a closed-loop update mechanism: if the DBA adopts or corrects the system's recommended optimization suggestions, the system automatically vectorizes the (SQL pattern, execution plan, effect evaluation) triple and appends it to the vector index, along with a version number, timestamp, and scenario tag. Simultaneously, the system comprehensively scores each piece of knowledge according to the Knowledge Quality Score (KQS) system, with score weights including performance improvement rate (40%), usage frequency (30%), DBA score (20%), and time decay (10%). Knowledge with a score below a threshold (e.g., 0.6) is automatically marked as low-quality and downgraded. For multiple conflicting experiences with the same SQL pattern, the system uses a clustering algorithm based on MinHash and Locality Sensitive Hashing (LSH) to identify conflicts and automatically selects the optimal experience through a comprehensive score weighted by time decay and effect.

[0027] Furthermore, the system distributes all SQL traffic according to a preset ratio. The default configuration is that 5% of the traffic goes through the RAG optimized path (experimental group), and 95% of the traffic goes through the traditional optimized path (control group). The distribution is based on the modulo operation of the SQL statement's hash value, ensuring that the same SQL template always enters the same group and avoiding test bias. The system continuously monitors key performance indicators for both groups of traffic, including: average SQL execution time (milliseconds), resource consumption (CPU time, disk I / O counts, network transfer bytes), execution success rate (whether execution failed due to hints), and execution plan generation time. Monitoring data is aggregated hourly to generate comparative reports. When the average execution time of the experimental group decreases by more than a preset threshold (default 10%) compared to the control group and continues to run stably for more than 72 hours, the system automatically and gradually increases the proportion of traffic on the RAG optimized path (e.g., from 5% to 20%, then to 50%, and finally to 100%). When the experimental group's effect is not significant or performance degradation occurs, the system automatically rolls back to the control group strategy and triggers an alarm, notifying the DBA to intervene and analyze. The proportion of A / B testing and the supported traffic range (5%~20%) can be dynamically configured by the DBA according to the business sensitivity. Core transaction systems can be set to a lower proportion, while non-core systems can be set to a higher proportion.

[0028] Furthermore, the system employs a Role-Based Access Control (RBAC) model, dividing users into three role levels: administrators, DBAs, and read-only users. Administrators possess full management permissions for the knowledge base (including knowledge review, deletion, and degradation policy configuration); DBAs have permissions to query, adopt, correct, and reject knowledge, as well as the permission to manually trigger knowledge entry into the database; read-only users can only query and browse knowledge content and cannot perform any modification operations. All knowledge base operations (query, write, modify, and delete) are recorded in audit logs, which include the operator, operation time, operation type, operation object, and data status before and after the operation. Audit logs are retained for no less than 180 days. Sensitive SQL feature vectors (containing business-related information such as table names and column names) are encrypted using the AES-256 symmetric encryption algorithm before being written to shared storage, ensuring that the original knowledge content cannot be recovered even if the storage medium is leaked. Vector data is transmitted between database nodes using the TLS 1.3 encryption protocol to prevent network eavesdropping. Before knowledge is added to the database, an SQL security audit is performed. The system has a built-in high-risk operation detection rule base (covering high-risk SQL patterns such as DROP TABLE, DELETE without WHERE, TRUNCATE, ALTER TABLE, etc.). SQL text containing high-risk operations is intercepted, marked as "suspicious knowledge," and pushed to the DBA for manual review and confirmation before it can be added to the database. At the same time, the system performs injection attack feature detection on the SQL patterns of the knowledge to be added to the database (such as detecting whether it contains SQL injection features such as OR '1'='1', UNION SELECT, etc.) to prevent malicious attacks.

[0029] Example 1: Deploying the system of the present invention on a specific database coordination node (CN): First, a new vectorization module (Vectorization_Module) is added to the CN node. This module includes a vector generation submodule, an index construction submodule, and a retrieval submodule. The vector generation submodule integrates the inference interface of the BGE vector encoding model, loads pre-trained model weights, and provides the ability to generate 1024-dimensional vectors in batches. The index construction submodule implements dynamic construction and incremental updates of the index based on the HNSW algorithm, supports dynamic configuration of the M (default 16) and ef_construction (default 200) parameters, and calls the AVX2 instruction set to accelerate vector distance calculation (L2 distance and cosine similarity). The retrieval submodule implements Top-K approximate nearest neighbor search and supports dynamic adjustment of the K value.

[0030] Vector data is persisted to the shared storage of data nodes via the database's Write-Ahead Log (WAL) mechanism, reusing the database kernel's original transaction commit, backup and recovery, and replica synchronization capabilities. Once the vector index is deployed, no data migration from an external vector database is required, achieving a completely zero-data migration deployment. The system is configured with an independent retrieval thread pool (4 core threads, maximum 8 threads) and a retrieval timeout threshold (default 5 milliseconds) to adapt to performance requirements under different hardware configurations. Simultaneously, L1 / L2 / L3 three-level caching is implemented to ensure millisecond-level response times for high-frequency retrievals.

[0031] Example 2: After the logical plan of the SQL compilation process is generated and before the physical execution plan is selected, a RAG retrieval interceptor (RAGInterceptor) is inserted. The interceptor first normalizes the input SQL text, replaces specific constant values ​​with placeholders (e.g., replaces WHERE id = 123 with WHERE id = ?), and generates a unique identifier for the SQL pattern.

[0032] Subsequently, the interceptor obtains a summary of statistical information of the current database (including the number of rows in each table, the index cardinality, the column value distribution histogram, etc.) and obtains the historical execution fingerprint of the SQL template from the execution plan cache (including the historical average execution time, the historical number of rows scanned, the historical operator types used, etc.). The normalized SQL text, the summary of statistical information and the historical execution fingerprint are concatenated to construct a multidimensional retrieval query.

[0033] The system provides a global switch (enabled by default) and fine-grained control (RAG functionality can be enabled / disabled individually at the database or table level). It also supports synchronous retrieval mode (blocking while waiting for retrieval results) and asynchronous retrieval mode (retrieval results are automatically downgraded to the default optimization strategy if they do not return after a timeout). The retrieval result cache validity period is set (default 300 seconds), and within this period, the same SQL template will be directly cached.

[0034] Example 3: When the SQL execution time exceeds the preset slow query threshold (default 1 second), the system automatically triggers the knowledge entry process: Collect the complete text of the SQL, the EXPLAIN execution plan (operator sequence, join order, index usage), and actual execution statistics (execution time, number of rows scanned, temporary table usage, etc.). Concatenate the above information into structured knowledge text according to a preset format, call the vector encoding model to encode it into a 1024-dimensional vector, generate an initial value for the Knowledge Quality Score (KQS) (based on a performance improvement rate of 0, usage frequency of 0, a default DBA score of 3.5, and a time decay factor of 1.0, resulting in an overall initial KQS of 0.5), write it into the vector index and attach a timestamp (accurate to milliseconds), version number (initially 1.0), and scenario label (such as "OLTP query optimization" or "report query optimization").

[0035] When the DBA adopts or corrects the RAG optimization suggestion, the system automatically generates a triple (SQL mode, final execution plan parameters, effect evaluation), calls the vector encoding model to encode it, and appends it to the vector index. At the same time, the KQS score of this knowledge is updated (calculated by weighting four factors: performance improvement rate 40%, usage frequency 30%, DBA score 20%, and time decay 10%).

[0036] The system supports knowledge version management, allowing users to filter and query historical knowledge by time range or scenario tags. Knowledge with a KQS score below 0.6 is automatically marked as low quality and downgraded. Knowledge that has not been used by any SQL queries for three consecutive months is automatically subject to an expiration cleanup process, removed from the active index, and archived to cold storage.

[0037] When an anomaly occurs during the data entry process (such as vector encoding service timeout or insufficient storage space), the system will automatically retry 3 times, with an exponential backoff interval between each retry (1 second, 2 seconds, and 4 seconds). If a retry fails, an error log will be recorded and an alarm will be issued to ensure that knowledge data is not lost.

[0038] Application Example 4: The system supports flexible adjustment of configuration parameters according to different business scenarios: (1) Performance optimization scenario: Top-K is set to 3, similarity threshold is set to 0.75, and HNSW's ef_search parameter is set to 200 to prioritize recall accuracy; (2) Fault diagnosis scenario: Top-K is set to 5 to expand the recall scope to cover more possible causes, the similarity threshold is reduced to 0.6, and the root cause analysis results of related alarm events are jointly retrieved; (3) Capacity warning scenario: Add historical execution frequency and resource consumption trend dimensions to the Query to trigger targeted expansion or SQL rewriting suggestions.

[0039] The system supports a post-execution trigger mode (i.e., RAG retrieval is triggered asynchronously after SQL execution, recording only optimization suggestions without affecting the current execution), suitable for scenarios such as core trading systems that are extremely sensitive to response latency. It also supports configuring the A / B test traffic ratio (default 5%, adjustable range 0~20%) to gradually verify and promote optimization strategies.

[0040] The system provides a unified monitoring and alarm interface, supporting the collection of key indicators such as RAG retrieval hit rate, retrieval time distribution, and KQS score distribution through open-source monitoring systems such as Prometheus, and integrating them into the existing operation and maintenance monitoring platform.

[0041] Example 5: Deploy a KQS evaluation system to perform real-time quality monitoring of all knowledge items in the knowledge base: The KQS score is calculated using a weighted average of four dimensions: performance improvement rate (40%), usage frequency (30%), DBA score (20%, using a 5-point scale), and time decay (10%). Knowledge with a comprehensive score below 0.6 is marked as low quality and automatically downgraded during the recall process (only considered as an alternative when high-quality knowledge cannot be matched).

[0042] The system implements an A / B testing framework, diverting SQL traffic to the RAG optimization path at a configurable ratio of 5% to 20%, and continuously monitoring the optimization effect. Key metrics include execution time, resource consumption, and success rate. When the RAG optimization group consistently outperforms the control group (e.g., execution time decreases by more than 10% and runs stably for 72 hours), the system automatically increases the proportion of RAG optimization traffic.

[0043] The system establishes a knowledge review process, automatically generating a weekly knowledge quality report that lists newly added knowledge, the top 10 high-quality knowledge items, and a list of low-quality knowledge items for DBAs to review regularly. Low-quality knowledge items can be downgraded or deleted with a single click. When the knowledge quality score fluctuates abnormally (e.g., the average KQS of newly added knowledge drops sharply by more than 20% within a certain period), the system triggers an alert to notify DBAs to intervene and analyze the situation.

[0044] The system supports knowledge graph visualization, using SQL patterns as nodes and knowledge relationships (such as similar optimization scenarios) as edges to intuitively display the overall structure and coverage of the knowledge base.

[0045] Example 6: (I) Knowledge Base Access Control: The system adopts a role-based access control (RBAC) model, dividing users into three role levels: administrator, DBA, and read-only user. Administrators have full management permissions for the knowledge base (including knowledge review, deletion, and degradation policy configuration); DBAs have permissions to query, adopt, correct, and reject knowledge; read-only users can only query and browse knowledge content. All operation records are audited and retained for no less than 180 days.

[0046] (ii) Vector data encryption: Sensitive SQL feature vectors are encrypted and stored using the AES-256 symmetric encryption algorithm, and TLS 1.3 encryption is enabled during transmission.

[0047] (III) Malicious SQL Filtering: SQL security audits are performed before knowledge is added to the database. A built-in high-risk operation detection rule base (covering high-risk SQL patterns such as DROP TABLE, DELETE without WHERE, TRUNCATE, ALTER TABLE, etc.) is used to intercept SQL text containing high-risk operations, mark it as "suspicious knowledge," and push it to the DBA for manual review. At the same time, SQL injection characteristics (such as OR '1'='1', UNION SELECT, etc.) are detected to prevent malicious SQL from polluting the knowledge base.

[0048] In one embodiment, S100 includes: S101. Collect slow query data according to preset trigger conditions; S102. Collect alarm events, root cause and remediation action records, experience documents and historical work order records; S103. Perform standardized preprocessing on the slow query data, alarm events, root cause and remediation action records, experience documents and historical work order records. S104. Based on the preset data splicing strategy, splice the preprocessed slow query data, alarm events, root cause and remedial action records, experience documents and historical work order records to generate knowledge text.

[0049] In this embodiment, slow query data is automatically collected based on preset triggering conditions. Specifically, the system pre-configures a slow query threshold (default setting is 1 second). When the execution time of Structured Query Language (SQL) exceeds this threshold, the kernel actively triggers the collection process to capture the complete text of the SQL, the execution plan obtained through the EXPLAIN command (including the specific operator execution sequence), and real-time execution statistics. Simultaneously, the system comprehensively collects various alarm events, corresponding root cause analyses, and records of implemented remediation measures by monitoring the database alarm component in real time. Furthermore, the system connects to external knowledge bases or ticketing systems via an Application Programming Interface (API) to automatically retrieve experience documents accumulated by database administrators (DBAs) and historical ticket processing records.

[0050] The preset triggering conditions include: when the execution time of an SQL statement exceeds the default threshold of 1 second, the kernel automatically triggers the collection process to capture the complete text of the SQL, the execution plan obtained through the EXPLAIN command (including operator sequence, join order, index usage, operator type and parallelism), and real-time execution statistics. The slow query threshold can be dynamically adjusted by the DBA according to the business scenario.

[0051] The collected multi-source heterogeneous data then enters the standardization preprocessing stage. In this stage, the system performs deep cleaning on various types of raw text, removing invalid characters and noisy data, and standardizing the data format. Crucially, for semi-structured data such as execution plans, the system performs targeted structured parsing, accurately extracting core fields that directly affect query performance, such as join order, index usage, operator type, and parallelism, transforming unstructured text into computable structured information.

[0052] After standardized preprocessing, the system operates according to a preset data concatenation strategy. For slow query data, the SQL text, execution plan operator sequence, and statistical information are concatenated in a fixed order; for alarm root cause records, alarm type, fault phenomenon, root cause, and remedial measures are concatenated; for experience documents, they are split into semantic paragraphs and then parsed in a structured manner. Finally, all preprocessed multi-source data are horizontally concatenated according to a unified paradigm and delimiters to generate continuous and complete knowledge text, thus providing standardized and semantically coherent input materials for subsequent vectorized encoding.

[0053] In one embodiment, S200 includes: S201. The knowledge text is vectorized and encoded using a vector coding model to obtain a knowledge text vector. S202. The hierarchical navigable small-world algorithm is used to calculate dynamic parameters based on the knowledge text vector; S203. Construct a vector index based on the dynamic parameters and the knowledge text vector; S204. Write the vector index into the shared storage of the data node through the database's write-ahead log mechanism.

[0054] In this embodiment, a vector encoding model is invoked to vectorize the generated knowledge text. Specifically, the system integrates a general vector encoding model (such as BGE or the text2vec-chinese model). The structured knowledge text generated in the previous step is input into this model, and the model's deep neural network calculates and outputs a fixed-dimensional vector representation. To balance semantic representation capability and computational efficiency, a 1024-dimensional vector dimension can be used, mapping each piece of knowledge text to a dense vector point in a high-dimensional space, so that semantically similar knowledge texts have high vector similarity in this space.

[0055] The vector encoding model is preferably a BGE (BAAI General Embedding) series model or a text2vec-chinese model, which encodes knowledge text into a dense vector representation of 1024 dimensions. This dimension strikes a balance between semantic representation capability and computational efficiency, enabling semantically similar knowledge texts to have high vector similarity in high-dimensional space.

[0056] After vectorization encoding, the system employs the Hierarchical Navigable Small World (HNSW) algorithm to calculate dynamic parameters based on the generated knowledge text vectors and construct an efficient vector index. The core principle of the HNSW algorithm is to build a multi-level graph structure, with the bottom layer containing all vector nodes, and each subsequent layer being a subset of the nodes of the next layer, decreasing in size progressively. During index construction, the system dynamically calculates and adjusts several key parameters based on the vector distribution and target retrieval performance. These dynamic parameters include: the maximum number of connections per node in each layer (usually denoted as M, controlling graph density and retrieval accuracy), the size of the dynamic candidate list during index construction (usually denoted as ef_construction, affecting index quality and construction speed), and the hierarchical partitioning strategy of the multi-level graph structure. These parameters are not fixed but are adaptively calculated and optimized based on the size of the actual vector dataset, dimensionality distribution characteristics, and hardware resources to achieve the optimal balance between retrieval accuracy and query latency.

[0057] The dynamic parameters include: the maximum number of connections per node in each layer (denoted as M, ranging from 12 to 64, with a default of 16). This parameter controls the density of the graph structure and retrieval accuracy; a larger M value results in higher retrieval accuracy but also increases memory usage and construction time. The dynamic candidate list size during index construction (denoted as ef_construction, ranging from 100 to 500, with a default of 200) affects index quality and construction speed; a larger value results in higher index quality but longer construction time. The layer partitioning strategy for the multi-layer graph structure adaptively determines the number of layers from the top to the bottom based on the dimensionality distribution characteristics of the vectors. These parameters are adaptively calculated and optimized based on the size of the actual vector dataset (total number of vectors), dimensionality distribution characteristics (such as the variance of each dimension), and hardware resource conditions (available memory size, number of CPU cores) to achieve the best balance between retrieval accuracy and query latency.

[0058] Based on the calculated dynamic parameters and all knowledge text vectors, the system formally constructs a vector index. The specific construction process is as follows: all vector points are inserted one by one into the HNSW graph structure. Starting from the top level, for each newly inserted vector, its nearest neighbor node in each layer is found and connections are established. The number of connections is constrained by the aforementioned dynamic parameters. After the index is constructed, the system can quickly locate the Top-K knowledge vectors most similar to the target query vector during retrieval by greedily searching downwards from the top level. The entire index construction and storage process is deployed on the database's CoordinatorNode (CN) and fully utilizes Single Instruction Multiple Data (SIMD) instruction sets (such as the AVX2 advanced vector extension instruction set) to accelerate vector distance calculations in parallel, significantly improving construction and retrieval efficiency.

[0059] After the index is built, the system writes the vector index to the shared storage of the data nodes using the database's write-ahead log (WAL) mechanism, based on a multi-level caching strategy. The multi-level caching strategy plays two roles here: firstly, it sets up L1 and L2 caches in memory (caching recent search results and popular vector representations respectively) to ensure millisecond-level response speeds for frequently accessed index data; secondly, it persists the complete vector index to disk. The persistence process reuses the database kernel's original write-ahead log (WAL) mechanism. WAL is the core protocol for ensuring data consistency and persistence in the database, and its basic principle is "to force the log records of modification operations to be written to disk before the data itself is modified." When the vector index needs to be written to shared storage, the system first writes the modification operations of the index data sequentially to the WAL buffer in log form and synchronizes them to disk, and then asynchronously writes the vector index data to the shared storage of the data nodes. This design fully reuses the existing transaction mechanism, backup and recovery capabilities, and high availability architecture of the database kernel, enabling zero-data migration deployment of vector indexes. This means that data does not need to be imported or exported from an external independent vector database. Instead, it shares the same set of storage resources and transaction guarantee mechanisms with the database kernel, significantly reducing storage redundancy and I / O overhead. At the same time, it ensures that the vector indexes can be fully recovered through WAL logs in the event of system failure, without losing any knowledge data.

[0060] The system implements a three-level caching mechanism to ensure millisecond-level response times for high-frequency searches: L1 Cache (Memory Level): Stores the results of the most recent 1000 SQL queries, using a key-value pair structure. The key is the hash value of the SQL normalized text, and the value is the corresponding list of knowledge items in the query results. When a match is found, the results are returned directly, with a response time of less than 1 millisecond. L2 cache (memory level): Stores vector representations of popular SQL patterns. For SQL patterns that are hit more frequently in the L1 cache than a threshold (e.g., more than 10 hits per hour), their vector representations are preloaded into memory to accelerate the approximate nearest neighbor search process of vector retrieval. L3 cache (disk level): Stores a persistent copy of historical search results, used for pre-warming caching after system restart to reduce search latency during cold start.

[0061] Cache management employs the Least Recently Used (LRU) algorithm, prioritizing the eviction of the least recently accessed cache entry when cache space is insufficient. Upon cache hit, the system verifies the validity of the cache entry. If database statistics have changed by more than 10% since the cache was created (e.g., significant changes in key parameters such as table size and index selectivity), the cache entry automatically expires, requiring a complete re-execution of the retrieval process. The system periodically (by default, hourly) cleans up expired cache entries to ensure a cache hit rate above 80%.

[0062] In one embodiment, S400 includes: S401. Based on the multidimensional retrieval query, the vector index is used to perform multi-way recall of vector retrieval, full-text retrieval and strategy matching in parallel to obtain multi-way recall results; S402. Merge the multi-path recall results to obtain an initial candidate knowledge item set. Input the initial candidate knowledge item set into a cross encoder for deep interactive encoding to generate a relevance score for each candidate knowledge item. S403. Sort the correlation scores according to a preset order, and select a preset number of historical experience knowledge items based on the sorting results.

[0063] In this embodiment, after the multidimensional retrieval query is constructed, the system immediately enters the multi-path recall and fine-tuning screening stage. This stage is based on parallelization strategy and deep semantic interaction to ensure that the most relevant historical experience is quickly and accurately located from the massive knowledge base.

[0064] First, based on the constructed multidimensional retrieval query, the system triggers three independent recall channels in parallel to achieve multi-path recall. The first channel is the vector retrieval channel. The system performs an approximate nearest neighbor search on the semantic vector part of the multidimensional retrieval query with the previously constructed hierarchical navigable small world (HNSW) vector index. By calculating the cosine similarity or Euclidean distance between vectors, it quickly recalls the top-K knowledge items that are most similar at the semantic level. This channel is good at capturing the deep semantic relationship between the query and the knowledge text. The second channel is the full-text retrieval channel. The system uses the Best Matching 25 (BM25) algorithm to perform full-text retrieval on the keywords in the query. BM25 is the core ranking function of mainstream search engines. It is based on the principles of Term Frequency (TF) and Inverse Document Frequency (IDF) and introduces term saturation and document length normalization factors to calculate a relevance score for each document, effectively measuring the degree of matching between keywords and knowledge text at the lexical level. The third path is the strategy matching channel. The system uses SQL pattern regular expressions to perform precise pattern matching on the normalized SQL structure in the query, directly hitting knowledge entries that are historically identical to the SQL structure. This channel ensures zero omissions in the recall of known problem patterns. The three-way retrieval is executed in parallel in the database kernel process, making full use of multi-core CPU resources and unifying the result sets recalled by each path.

[0065] Subsequently, the system merges the three recall results. The merging process includes deduplication, removing identical knowledge items that appear repeatedly across channels, and preliminary score normalization, mapping the original scores from different channels to comparable units, thus forming an initial set of candidate knowledge items of moderate size. This initial candidate set is much smaller in number than the full knowledge base, but it is highly focused on the knowledge scope relevant to the current query.

[0066] After merging, the system inputs the entire initial set of candidate knowledge items into a cross-encoder for deep interactive encoding. The cross-encoder is a deep semantic matching model based on the Transformer architecture. Its core feature is that it concatenates the query with each candidate knowledge item into a complete input sequence, which is then fed into the model for bidirectional, joint attention computation. Internally, each token in the query can engage in deep information interaction and semantic fusion with each token in the candidate knowledge items. The model captures fine-grained semantic associations and logical matching patterns between them through a multi-layered self-attention mechanism. This deep joint encoding method can identify complex semantic relationships that simple vector similarity or keyword matching cannot discover, such as synonym substitution, implied reasoning, and contextual dependencies. After computation by the cross-encoder, the system outputs a relevance score between 0 and 1 for each knowledge item in the candidate set. This score accurately reflects the true semantic matching degree between the knowledge item and the current SQL execution context.

[0067] Finally, the system sorts all candidate knowledge items by relevance score according to a preset order. Typically, a descending order is used, placing the highest-scoring knowledge item at the top. After sorting, the system selects the top-ranked knowledge items from the sorted list based on a preset Top-K configuration (e.g., taking the top 3), which are then used as the final selected historical experience knowledge items. These knowledge items not only semantically match the current SQL, but have also undergone thorough validation at the lexical and structural levels, and have received the finest relevance calibration through deep interaction with the cross-encoder, thus providing the highest quality knowledge input for subsequent optimizer hint transformation and injection stages.

[0068] The system sorts all candidate knowledge items by relevance score according to a preset order (descending order), placing the highest-scoring knowledge item at the top. After sorting, the system selects the top K knowledge items from the sorted list based on a preset Top-K configuration (preferably the top 3, with the K value dynamically adjustable by the DBA within the range of 1 to 10 according to the actual business scenario), which are then used as the final selected historical experience knowledge items. The cross-encoder preferably adopts a deep semantic matching model based on the BERT architecture, concatenating the retrieval query with each candidate knowledge item into a complete input sequence. Through a multi-layer self-attention mechanism, bidirectional and joint attention calculations are performed to capture complex semantic interaction relationships at the token level, outputting a relevance score between 0 and 1.

[0069] In one embodiment, S500 includes: S501. Parse the historical experience knowledge items, extract the execution plan related parameter information from each historical experience knowledge item, and generate a candidate knowledge item set based on the execution plan related parameter information; S502. Determine whether the candidate knowledge item set contains multiple historical experience knowledge items corresponding to different optimization directions under the same SQL mode; S503. If it exists, select a recommended knowledge item from multiple historical experience knowledge items, and obtain the execution plan related parameter information corresponding to the recommended knowledge item from the candidate knowledge item set; S504. If it does not exist, directly obtain the execution plan-related parameter information from the candidate knowledge item set; S505. Convert the obtained execution plan-related parameter information into a first optimizer suggestion; S506. Check if there is a second optimizer prompt; S507. If the second optimizer suggestion exists, the second optimizer suggestion shall be used first. S508. If the second optimizer suggestion does not exist, then the first optimizer suggestion shall be used; S509. Inject the optimized algorithm hints into the physical execution plan selector, adjust the physical operators in conjunction with the cost model, and execute the physical execution plan according to the adjusted physical operators.

[0070] In this embodiment, after the historical experience knowledge items are filtered, the system enters the key transformation and injection stage, which transforms the historical experience in text form into optimizer hints (Hints for short) that can directly affect the generation of the execution plan, and drives the final generation of the physical execution plan according to the predetermined priority strategy.

[0071] First, the system performs in-depth analysis on the selected historical experience knowledge items. Each knowledge item, upon being entered into the database, has its core parameter information related to the execution plan stored in a structured manner, including but not limited to the table join order, the names of the indexes used by each table, the degree of parallelism (DOP), the join method (such as nested loop join, hash join, sort-merge join, etc.), and the partition pruning strategy. The system extracts these parameters one by one from these knowledge items and organizes them into a candidate knowledge item set.

[0072] Subsequently, the system performs conflict detection on the candidate knowledge item set. The judgment logic is as follows: check whether there are multiple historical experience knowledge items in the set that belong to the same SQL pattern (i.e., the normalized SQL structure skeleton, such as SELECT FROM t1 JOIN t2 WHERE t1.id = ?), and whether the execution plan parameters carried by these knowledge items point to different optimization directions. For example, one suggests using index A, and another suggests using index B; or one suggests using hash join, and another suggests using nested loop join. If such a conflict is detected, the system triggers an intelligent conflict resolution mechanism to handle it.

[0073] The conflict resolution mechanism employs a combination of strategies. First, the system uses a clustering algorithm based on MinHash and Locality Sensitive Hashing (LSH) to confirm that these knowledge items indeed belong to the same conflicting SQL pattern. Then, the system calculates a comprehensive score for each conflicting knowledge item. The score is a weighted composite of two parts: a time decay factor (the more recent the knowledge item's creation, the higher its weight, using an exponential decay function) and an effectiveness score (the percentage performance improvement actually achieved by the knowledge item after its historical adoption). The formula for the comprehensive score is: Final Score = Time Decay Factor × Effectiveness Score. From the multiple conflicting knowledge items, the system selects the one with the highest comprehensive score as the final recommended knowledge item and extracts the execution plan parameters corresponding to this recommended knowledge item from the candidate knowledge item set. If there are no conflicts in the candidate knowledge item set (i.e., all knowledge items suggest the same optimization direction), or if the set contains only one knowledge item, the system directly obtains the execution plan parameters from that set.

[0074] After parameter extraction, the system converts the obtained execution plan parameters into first optimizer hints (RAG optimizer hints). The conversion process is a formatted mapping: the extracted parameters such as join order, index name, parallelism, and join method are concatenated into valid hint strings according to the hint syntax supported by the database optimizer. For example, for index selection, a hint in the form of / + INDEX(table_name index_name) / can be generated; for join order, a hint in the form of / + LEADING(table1 table2) / can be generated.

[0075] After the conversion is complete, the system enters the priority determination stage. The system checks if a second optimizer hint already exists in the current SQL compilation environment; this is a hint manually added by the database administrator (DBA). DBA-manual hints are typically implemented by embedding specific comment directives directly into the SQL text, and their priority is set to the highest level. If the system detects the existence of such a second optimizer hint, it unconditionally prioritizes and uses the DBA-manual hint, completely bypassing the hint generated by RAG. If no manual hints are detected, the system uses the first optimizer hint generated by RAG. After using the RAG-generated hint, the system still checks if a historically optimal plan is stored in the execution plan cache. If it exists and its validity has not expired (i.e., the statistical information change does not exceed 10%), the cached plan is reused first; otherwise, the system proceeds to the next stage.

[0076] Finally, the system injects the determined optimizer hints (whether generated by RAG or manually provided by the DBA) into the physical execution plan selector. The physical execution plan selector is a core component of the database kernel responsible for selecting the optimal path from multiple candidate physical execution paths. It typically estimates each candidate path based on a cost model. The cost model calculates the estimated CPU time, I / O operations, and network traffic for each execution path based on factors such as table size, index selectivity, data distribution statistics, and network transmission overhead, and then weights and summarizes these into a numerical total cost. After the hint is injected, the selector is subject to the mandatory constraints of the hint when enumerating combinations of physical operators. For example, it may force the specification of a certain index, force a fixed table join order, or force a set parallelism. Under these constraints, the selector fine-tunes the remaining free parameters in conjunction with the cost model, ultimately generating a physical operator tree that conforms to the hint instructions and has the lowest estimated cost. Subsequently, the database kernel executes the physical execution plan according to the adjusted physical operator tree, completing the entire compilation and execution process of the SQL statement.

[0077] When an anomaly occurs during RAG retrieval or Hint injection, the system will execute the following preset degradation strategies sequentially to ensure that the normal compilation and execution of SQL statements are not affected: (1) First degradation strategy: When RAG retrieval fails (such as vector index is unavailable, retrieval timeout or return of empty results), the system automatically skips the RAG process and uses the database default optimizer strategy to generate a physical execution plan; (2) Second downgrade strategy: When RAG retrieval is successful but the generated hint syntax is incompatible with the current database version, the system will convert the retrieved historical experience knowledge items into optimization suggestions in the form of text descriptions and push them to the DBA for manual reference. At the same time, the database default optimizer strategy will be used for execution. (3) Third degradation strategy: When the vector index is unavailable (e.g., the index file is corrupted or being rebuilt), the system automatically switches to the pure BM25 full-text search channel and performs knowledge retrieval based on keyword matching; (4) Fourth degradation strategy: When the end-to-end timeout of RAG retrieval exceeds the preset timeout threshold (default 10 milliseconds), the system automatically interrupts the retrieval process and uses the database default optimizer strategy to ensure that the RAG process does not significantly increase the end-to-end execution latency of SQL. (5) Fifth downgrade strategy: All downgrade operations are recorded in detailed logs (including downgrade triggering reasons, timestamps, SQL identifiers involved, etc.) for subsequent offline analysis and system optimization.

[0078] In one embodiment, S600 includes: S601. Collect the actual execution time, resource consumption, and number of scanned rows after executing the physical execution plan, as feedback indicator data; S602. In response to the interactive behavior prompted by the RAG optimizer, obtain the type of interactive behavior; S603. If the interaction behavior type is an adoption operation or a correction operation, then generate historical experience knowledge items based on the current SQL mode, the adopted or corrected physical execution plan, and the feedback indicator data. S604. Call the vector coding model to perform vectorized encoding on the historical experience knowledge items, write the encoded historical experience knowledge items into the vector index, and record the knowledge quality score of the historical experience knowledge items. S605. If the interaction behavior type is a rejection operation, the rejection reason is recorded, and the knowledge quality score of the historical experience knowledge item corresponding to the RAG optimizer prompt is reduced according to the rejection reason. S606. Dynamically adjust the recall priority of each historical experience knowledge item based on the knowledge quality score of each historical experience knowledge item.

[0079] In this embodiment, after the physical execution plan is completed, the system immediately enters the closed-loop self-evolution stage, and continuously updates and optimizes the quality of the knowledge base by collecting actual operation feedback and based on the interaction behavior of the database administrator (DBA).

[0080] The system automatically collects actual operational metrics after executing the physical execution plan, serving as feedback metrics data. Specifically, the collected metrics include: the actual execution time of the SQL statement (in milliseconds), resource consumption (covering CPU usage time, disk I / O operations and data volume, network transfer bytes, etc.), and the number of data rows actually scanned during execution (including full table scan rows, index scan rows, and rows processed by each operator). These feedback metrics data accurately reflect the effectiveness of the current optimization decisions in the actual operating environment and serve as the core basis for subsequent knowledge updates and quality assessments.

[0081] While collecting feedback metrics, the system simultaneously captures the database administrator's interactions with the RAG optimizer suggestions to determine the interaction types. These interactions are categorized into three types: adoption (the DBA fully accepts the system-recommended optimizer suggestions and directly uses the execution plan generated by those suggestions); correction (the DBA makes partial adjustments based on the system's recommendations (such as changing indexes, adjusting join order, or modifying parallelism) and then implements the changes); and rejection (the DBA completely rejects the system's recommendations and adopts other optimization methods or manually rewrites the SQL).

[0082] When the interaction type is an adoption or correction operation, the system triggers the knowledge generation and storage process. The system uses the current SQL pattern (i.e., the normalized SQL structure skeleton), the actual physical execution plan after adoption or correction (including all parameters such as the final join order, index selection, join method, and parallelism), and the collected feedback metrics data as a basis to package and generate a complete historical experience knowledge item. During the construction of this knowledge item, the feedback metrics are converted into an effect score field to quantify the actual performance improvement of the experience. Subsequently, the system calls the vector encoding model again to vectorize the historical experience knowledge item, obtaining the corresponding knowledge text vector. The encoded vector is then appended to the existing hierarchical navigable small world (HNSW) vector index, while simultaneously recording the metadata of the knowledge item, including the storage version number, timestamp, scene tag, and initial knowledge quality score (KQS). The KQS calculation is based on a multi-dimensional weighted formula: performance improvement rate contributes 40% weight (based on the comparison of execution time in feedback metrics with historical average levels), usage frequency contributes 30% weight (initially set to a lower base), DBA score contributes 20% weight (adoption operations are assigned a higher score, such as 4.5, and correction operations are assigned a lower score, such as 3.5), and time decay factor contributes 10% weight (the decay factor for newly added knowledge is 1). After combining the four weighted scores, new knowledge obtains an initial KQS score, which represents the system's preliminary assessment of its credibility and effectiveness.

[0083] If the interaction type is a rejection operation, the system does not generate new knowledge. Instead, it records the rejection reason (optional) entered by the DBA and lowers the knowledge quality score of the historical experience knowledge item corresponding to the rejected RAG optimizer suggestion. The specific reduction depends on the nature of the rejection reason. If the rejection is due to syntax incompatibility or environment differences, a moderate reduction will be applied; if the rejection is due to poor optimization or incorrect recommendation direction, a significant reduction will be applied. The score reduction operation updates the KQS field of the knowledge item in the vector index metadata in real time.

[0084] Finally, the system dynamically adjusts the recall priority of each knowledge item based on its historical experience knowledge score. In the subsequent multi-path recall stage, the vector retrieval channel incorporates the KQS score as a weighting factor in addition to similarity calculation. That is, for multiple knowledge items with similarity scores, the system prioritizes returning items with higher KQS scores; for knowledge items with a KQS score below a preset threshold (e.g., 0.6), the system automatically marks them as low-quality knowledge and downgrades them during the recall process, only considering them as alternatives when high-quality knowledge cannot be matched. In addition, for knowledge items that have not been used by any SQL queries for three consecutive months, the system automatically triggers an expiration cleanup process, removing them from the active index and archiving them to cold storage, ensuring that the vector index always retains highly active and high-quality knowledge resources. Through this closed-loop mechanism, the knowledge base continuously evolves with each actual operation by the DBA, achieving automatic accumulation and continuous preservation and appreciation of experience assets.

[0085] In one embodiment, if such a knowledge item exists, a recommended knowledge item is selected from multiple historical experience knowledge items, and the execution plan-related parameter information corresponding to the recommended knowledge item is obtained from the candidate knowledge item set, including: A text similarity clustering algorithm is used to cluster the SQL text corresponding to the historical experience knowledge items and generate cluster similarity. Historical experience knowledge items with cluster similarity higher than a preset threshold are grouped into the same knowledge group; For multiple historical experience knowledge items within the same knowledge group, calculate the comprehensive score separately; The historical experience knowledge item with the highest comprehensive score is selected as the recommended knowledge item.

[0086] In this embodiment, in the conflict resolution mechanism, when there are multiple historical experience knowledge items pointing to different optimization directions under the same SQL pattern within the candidate knowledge item set, the system uses intelligent clustering and comprehensive scoring mechanisms to accurately select the most recommended one as the final recommended knowledge item.

[0087] First, the system employs a text similarity-based clustering algorithm to perform clustering analysis on the original SQL texts corresponding to all historical experience knowledge items in the candidate knowledge item set. Specifically, the system uses the MinHash algorithm, a dimensionality reduction technique based on minimum hash signatures, which can compress text of arbitrary length into fixed-length integer signature vectors. This significantly reduces computational complexity while maintaining an approximately unbiased estimate of the Jaccard similarity (the ratio of the intersection to the union of two sets) between texts. After generating the MinHash signatures, the system further introduces Locality Sensitive Hashing (LSH) technology to assign signatures with high similarity to the same hash bucket with high probability, thereby achieving efficient clustering of massive amounts of text. During the clustering process, the system calculates the Jaccard similarity estimate between the MinHash signatures of each pair of SQL texts. This value is the clustering similarity, ranging from 0 to 1. A higher value indicates that the two SQL texts are more structurally similar.

[0088] Subsequently, the system groups the clustering results according to a preset similarity threshold (set to 0.7 in this scheme). When the cluster similarity of any two or more SQL texts is higher than this threshold, the system determines that they are structurally highly consistent, for example, both being query statements of the same type with multiple table joins and filtering conditions, and thus classifies these SQL texts and their corresponding historical experience knowledge items into the same knowledge group. If the cluster similarity is lower than or equal to the threshold, it is processed as an independent knowledge group and does not participate in subsequent intra-group conflict resolution.

[0089] Once grouped into the same knowledge group, this group may contain multiple historical experience knowledge items. Although they target the same SQL pattern, they may differ in their specific optimization strategies. For example, one experience might recommend using index A to perform an index scan, while another might recommend using a full table scan combined with a hash join. For multiple experiences within the same knowledge group, the system calculates the comprehensive score for each knowledge item. The overall score is composed of two weighted factors: the first is the time decay factor, which is calculated based on the creation time of the knowledge item. The closer to the present time, the higher the weight. An exponential decay function is used, for example, with a half-life of 30 days (the time required for the weight to decay to half of its initial value). The older the knowledge, the smaller its time factor. This design ensures that recent optimization practices are given higher reference value, reflecting the dynamic characteristics of database data distribution and query patterns as business changes. The second is the effectiveness score, which is derived from the percentage performance improvement recorded when the knowledge item was added to the database (i.e., the percentage decrease in SQL execution time after the experience was adopted compared to before optimization), as well as the frequency of adoption and feedback evaluation of the knowledge item in history. Experiences with more significant effects and more practical verification receive higher effectiveness scores. The final formula for calculating the overall score is: Overall Score = Time Decay Factor × Effectiveness Score. The two are coupled in a product form to ensure that only knowledge items that simultaneously meet the conditions of "good timeliness" and "excellent effectiveness" can receive a high score.

[0090] After calculating the comprehensive score of all historical experience knowledge items within the group, the system selects the one with the highest comprehensive score as the recommended knowledge item. Subsequently, the system accurately extracts the execution plan-related parameter information corresponding to the recommended knowledge item from the candidate knowledge item set, including join order, index selection, parallelism, join method, partition pruning strategy, etc., and uses it as the input basis for subsequent optimizer hint transformation, thereby ensuring that the final hint injected into the execution plan selector comes from the optimal and comprehensively weighed historical experience.

[0091] In one embodiment, a kernel-based intelligent database operation and maintenance device is provided, which corresponds one-to-one with the kernel-based intelligent database operation and maintenance method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the database intelligent operation and maintenance device based on kernel RAG of the present invention. The modules include: knowledge text generation module 10, vector index construction module 20, multi-dimensional retrieval construction module 30, multi-path recall module 40, prompt injection module 50, and feedback closed-loop update module 60. Detailed descriptions of each functional module are as follows: The knowledge text generation module 10 is used to collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text. The vector index construction module 20 is used to perform vector encoding on the knowledge text to obtain a knowledge text vector, and to construct a vector index based on the knowledge text vector. The multidimensional retrieval construction module 30 is used to intercept SQL requests through the RAG retrieval interceptor, normalize the SQL text in the SQL request, and concatenate the normalized SQL text with the current statistical information summary and historical execution fingerprint to construct a multidimensional retrieval query. The multi-path recall module 40 is used to perform multi-path recall, vector retrieval, full-text retrieval and strategy matching in parallel using the vector index based on the multi-dimensional retrieval query, merge the multi-path recall results and input them into the cross encoder for deep interactive encoding, and filter out historical experience knowledge items based on the deep interactive encoding results. The prompt injection module 50 is used to convert the historical experience knowledge items into RAG optimizer prompts and inject the RAG optimizer prompts into the physical execution plan selector to execute the physical execution plan according to a preset priority strategy; The feedback closed-loop update module 60 is used to collect feedback indicator data after executing the physical execution plan, and to perform closed-loop updates to the database based on the feedback indicator data.

[0092] In one embodiment, the knowledge text generation module 10 includes: Collect slow query data based on preset trigger conditions; Collect alarm events, root cause and remediation action records, experience documents and historical work order records; The slow query data, alarm events, root cause and remedial action records, experience documents and historical work order records are standardized and preprocessed. Based on the preset data splicing strategy, the preprocessed slow query data, alarm events, root cause and remedial action records, experience documents and historical work order records are spliced ​​together to generate knowledge text.

[0093] In one embodiment, the vector index construction module 20 includes: The knowledge text is vectorized using a vector encoding model to obtain a knowledge text vector. A hierarchical navigable small-world algorithm is used to calculate dynamic parameters based on the knowledge text vector; A vector index is constructed based on the dynamic parameters and the knowledge text vector; The vector index is written to the shared storage of the data nodes through the database's write-ahead log mechanism.

[0094] In one embodiment, the multi-channel recall module 40 includes: Based on the multidimensional retrieval query, the vector index is used to perform vector retrieval, full-text retrieval and strategy matching in parallel for multi-way recall, and multi-way recall results are obtained. The multi-path recall results are merged to obtain an initial candidate knowledge item set. The initial candidate knowledge item set is then input into a cross-encoder for deep interactive encoding to generate a relevance score for each candidate knowledge item. The relevance scores are sorted according to a preset order, and a preset number of historical experience knowledge items are selected based on the sorting results.

[0095] In one embodiment, the injection module 50 includes: The historical experience knowledge items are parsed, and the execution plan-related parameter information in each historical experience knowledge item is extracted. A candidate knowledge item set is generated based on the execution plan-related parameter information. Determine whether the candidate knowledge item set contains multiple historical experience knowledge items with different optimization directions under the same SQL schema; If it exists, select a recommended knowledge item from multiple historical experience knowledge items, and obtain the execution plan related parameter information corresponding to the recommended knowledge item from the candidate knowledge item set; If it does not exist, the execution plan-related parameter information in the candidate knowledge item set is directly obtained; The acquired execution plan-related parameter information is converted into a first optimizer suggestion; Check for the presence of a second optimizer suggestion; If the second optimizer suggestion exists, the second optimizer suggestion shall be used first; If the second optimizer suggestion is not available, the first optimizer suggestion shall be used; The optimized operator hints are injected into the physical execution plan selector, the physical operators are adjusted in conjunction with the cost model, and the physical execution plan is executed according to the adjusted physical operators.

[0096] In one embodiment, the feedback closed-loop update module 60 includes: The actual execution time, resource consumption, and number of scanned rows after executing the physical execution plan are collected as feedback indicator data. In response to the interaction behavior prompted by the RAG optimizer, obtain the interaction behavior type; If the interaction behavior type is an adoption operation or a correction operation, then historical experience knowledge items are generated based on the current SQL mode, the adopted or corrected physical execution plan, and the feedback indicator data. The vector encoding model is invoked to vectorize the historical experience knowledge items, the encoded historical experience knowledge items are written into the vector index, and the knowledge quality score of the historical experience knowledge items is recorded. If the interaction behavior type is a rejection operation, the rejection reason is recorded, and the knowledge quality score of the historical experience knowledge item corresponding to the RAG optimizer prompt is reduced according to the rejection reason; The recall priority of each historical experience knowledge item is dynamically adjusted based on the knowledge quality score of each item.

[0097] In one embodiment, if such a knowledge item exists, a recommended knowledge item is selected from multiple historical experience knowledge items, and the execution plan-related parameter information corresponding to the recommended knowledge item is obtained from the candidate knowledge item set, including: A text similarity clustering algorithm is used to cluster the SQL text corresponding to the historical experience knowledge items and generate cluster similarity. Historical experience knowledge items with cluster similarity higher than a preset threshold are grouped into the same knowledge group; For multiple historical experience knowledge items within the same knowledge group, calculate the comprehensive score separately; The historical experience knowledge item with the highest comprehensive score is selected as the recommended knowledge item.

[0098] Specific limitations regarding the kernel RAG-based intelligent database operation and maintenance device can be found in the aforementioned limitations of the kernel RAG-based intelligent database operation and maintenance method, and will not be repeated here. Each module in the aforementioned kernel RAG-based intelligent database operation and maintenance device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

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

[0100] In one embodiment, a computer device is provided, which may be a client, 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 devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the client-side functions or steps of a kernel-based RAG-based intelligent database operation and maintenance method.

[0101] 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, wherein the processor executes the computer program to perform the following steps: Collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text; The knowledge text is vector-encoded to obtain a knowledge text vector, and a vector index is constructed based on the knowledge text vector. The SQL request is intercepted by the RAG retrieval interceptor. The SQL text in the SQL request is normalized. The normalized SQL text is then concatenated with the current statistical information summary and the historical execution fingerprint to construct a multi-dimensional retrieval query. Based on the multidimensional retrieval query, the vector index is used to perform multi-way recall of vector retrieval, full-text retrieval and strategy matching in parallel. The multi-way recall results are merged and input into the cross encoder for deep interactive encoding. Historical experience knowledge items are then selected based on the deep interactive encoding results. The historical experience knowledge items are converted into RAG optimizer hints, and the RAG optimizer hints are injected into the physical execution plan selector to execute the physical execution plan according to the preset priority strategy; Collect feedback indicator data after executing the physical execution plan, and perform closed-loop updates to the database based on the feedback indicator data.

[0102] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon. When the computer program is executed by a processor, it performs the following steps: Collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text; The knowledge text is vector-encoded to obtain a knowledge text vector, and a vector index is constructed based on the knowledge text vector. The SQL request is intercepted by the RAG retrieval interceptor. The SQL text in the SQL request is normalized. The normalized SQL text is then concatenated with the current statistical information summary and the historical execution fingerprint to construct a multi-dimensional retrieval query. Based on the multidimensional retrieval query, the vector index is used to perform multi-way recall of vector retrieval, full-text retrieval and strategy matching in parallel. The multi-way recall results are merged and input into the cross encoder for deep interactive encoding. Historical experience knowledge items are then selected based on the deep interactive encoding results. The historical experience knowledge items are converted into RAG optimizer hints, and the RAG optimizer hints are injected into the physical execution plan selector to execute the physical execution plan according to the preset priority strategy; Collect feedback indicator data after executing the physical execution plan, and perform closed-loop updates to the database based on the feedback indicator data.

[0103] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0104] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, 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), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to 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.

[0106] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0107] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A database intelligent operation and maintenance method based on kernel RAG, characterized in that, Includes the following steps: Collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text; The knowledge text is vector-encoded to obtain a knowledge text vector, and a vector index is constructed based on the knowledge text vector. The SQL request is intercepted by the RAG retrieval interceptor. The SQL text in the SQL request is normalized. The normalized SQL text is then concatenated with the current statistical information summary and the historical execution fingerprint to construct a multi-dimensional retrieval query. Based on the multidimensional retrieval query, the vector index is used to perform multi-way recall of vector retrieval, full-text retrieval and strategy matching in parallel. The multi-way recall results are merged and input into the cross encoder for deep interactive encoding. Historical experience knowledge items are then selected based on the deep interactive encoding results. The historical experience knowledge items are converted into RAG optimizer hints, and the RAG optimizer hints are injected into the physical execution plan selector to execute the physical execution plan according to the preset priority strategy; Collect feedback indicator data after executing the physical execution plan, and perform closed-loop updates to the database based on the feedback indicator data.

2. The database intelligent operation and maintenance method based on kernel RAG as described in claim 1, characterized in that, Collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and concatenate the preprocessed multi-source heterogeneous data to generate knowledge text, including: Collect slow query data based on preset trigger conditions; Collect alarm events, root cause and remediation action records, experience documents and historical work order records; The slow query data, alarm events, root cause and remedial action records, experience documents and historical work order records are standardized and preprocessed. Based on the preset data splicing strategy, the preprocessed slow query data, alarm events, root cause and remedial action records, experience documents and historical work order records are spliced ​​together to generate knowledge text.

3. The database intelligent operation and maintenance method based on kernel RAG as described in claim 1, characterized in that, The knowledge text is vector-encoded to obtain a knowledge text vector, and a vector index is constructed based on the knowledge text vector, including: The knowledge text is vectorized using a vector encoding model to obtain a knowledge text vector. A hierarchical navigable small-world algorithm is used to calculate dynamic parameters based on the knowledge text vector; A vector index is constructed based on the dynamic parameters and the knowledge text vector; The vector index is written to the shared storage of the data nodes through the database's write-ahead log mechanism.

4. The database intelligent operation and maintenance method based on kernel RAG as described in claim 1, characterized in that, Based on the multidimensional retrieval query, the vector index is used to perform multi-path recall, including vector retrieval, full-text retrieval, and strategy matching in parallel. The multi-path recall results are merged and input into a cross-encoder for deep interactive encoding. Based on the deep interactive encoding results, historical experience knowledge items are filtered out, including: Based on the multidimensional retrieval query, the vector index is used to perform vector retrieval, full-text retrieval and strategy matching in parallel for multi-way recall, and multi-way recall results are obtained. The multi-path recall results are merged to obtain an initial candidate knowledge item set. The initial candidate knowledge item set is then input into a cross-encoder for deep interactive encoding to generate a relevance score for each candidate knowledge item. The relevance scores are sorted according to a preset order, and a preset number of historical experience knowledge items are selected based on the sorting results.

5. The database intelligent operation and maintenance method based on kernel RAG as described in claim 4, characterized in that, The historical experience knowledge items are converted into RAG optimizer hints, and the RAG optimizer hints are injected into the physical execution plan selector. The physical execution plan is then executed according to a preset priority strategy, including: The historical experience knowledge items are parsed, and the execution plan-related parameter information in each historical experience knowledge item is extracted. A candidate knowledge item set is generated based on the execution plan-related parameter information. Determine whether the candidate knowledge item set contains multiple historical experience knowledge items with different optimization directions under the same SQL schema; If it exists, select a recommended knowledge item from multiple historical experience knowledge items, and obtain the execution plan related parameter information corresponding to the recommended knowledge item from the candidate knowledge item set; If it does not exist, the execution plan-related parameter information in the candidate knowledge item set is directly obtained; The acquired execution plan-related parameter information is converted into a first optimizer suggestion; Check for the presence of a second optimizer suggestion; If the second optimizer suggestion exists, the second optimizer suggestion shall be used first; If the second optimizer suggestion is not available, the first optimizer suggestion shall be used; The optimized operator hints are injected into the physical execution plan selector, the physical operators are adjusted in conjunction with the cost model, and the physical execution plan is executed according to the adjusted physical operators.

6. The database intelligent operation and maintenance method based on kernel RAG as described in claim 1, characterized in that, Collect feedback metrics data after executing the physical execution plan, and perform closed-loop updates to the database based on the feedback metrics data, including: The actual execution time, resource consumption, and number of scanned rows after executing the physical execution plan are collected as feedback indicator data. In response to the interaction behavior prompted by the RAG optimizer, obtain the interaction behavior type; If the interaction behavior type is an adoption operation or a correction operation, then historical experience knowledge items are generated based on the current SQL mode, the adopted or corrected physical execution plan, and the feedback indicator data. The vector encoding model is invoked to vectorize the historical experience knowledge items, the encoded historical experience knowledge items are written into the vector index, and the knowledge quality score of the historical experience knowledge items is recorded. If the interaction behavior type is a rejection operation, the rejection reason is recorded, and the knowledge quality score of the historical experience knowledge item corresponding to the RAG optimizer prompt is reduced according to the rejection reason; The recall priority of each historical experience knowledge item is dynamically adjusted based on the knowledge quality score of each item.

7. The database intelligent operation and maintenance method based on kernel RAG as described in claim 5, characterized in that, If it exists, then select a recommended knowledge item from multiple historical experience knowledge items, and obtain the execution plan related parameter information corresponding to the recommended knowledge item from the candidate knowledge item set, including: A text similarity clustering algorithm is used to cluster the SQL text corresponding to the historical experience knowledge items and generate cluster similarity. Historical experience knowledge items with cluster similarity higher than a preset threshold are grouped into the same knowledge group; For multiple historical experience knowledge items within the same knowledge group, calculate the comprehensive score separately; The historical experience knowledge item with the highest comprehensive score is selected as the recommended knowledge item.

8. A database intelligent operation and maintenance device based on kernel RAG, characterized in that, The database intelligent operation and maintenance device based on kernel RAG includes: The knowledge text generation module is used to collect multi-source heterogeneous data, preprocess the multi-source heterogeneous data, and splice the preprocessed multi-source heterogeneous data to generate knowledge text. The vector index construction module is used to perform vector encoding on the knowledge text to obtain a knowledge text vector, and to construct a vector index based on the knowledge text vector. The multidimensional retrieval construction module is used to intercept SQL requests through the RAG retrieval interceptor, normalize the SQL text in the SQL request, and concatenate the normalized SQL text with the current statistical information summary and historical execution fingerprint to construct a multidimensional retrieval query. The multi-path recall module is used to perform multi-path recall, vector retrieval, full-text retrieval and strategy matching in parallel using the vector index based on the multi-dimensional retrieval query. The multi-path recall results are merged and input into the cross encoder for deep interactive encoding. Historical experience knowledge items are then selected based on the deep interactive encoding results. The hint injection module is used to convert the historical experience knowledge items into RAG optimizer hints and inject the RAG optimizer hints into the physical execution plan selector to execute the physical execution plan according to a preset priority strategy. The feedback closed-loop update module is used to collect feedback indicator data after executing the physical execution plan, and to perform closed-loop updates to the database based on the feedback indicator data.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a kernel-based RAG-based intelligent database operation and maintenance program stored in the memory and capable of running on the processor. When the kernel-based RAG-based intelligent database operation and maintenance program is executed by the processor, it implements the steps of the kernel-based RAG-based intelligent database operation and maintenance method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a database intelligent operation and maintenance program based on kernel RAG. When the kernel RAG-based database intelligent operation and maintenance program is executed by the processor, it implements the steps of the database intelligent operation and maintenance method based on kernel RAG as described in any one of claims 1-7.

Images