Database operation and maintenance decision-making method and device based on large language model and medium

Abstract

The invention relates to the technical field of database operation and maintenance, in particular to a database operation and maintenance decision-making method and device based on a large language model.The method comprises the steps that real-time operation indexes and historical log data of a database are collected, and multi-dimensional time sequence features are extracted; and analyzing the characteristics by using a large language model, judging whether a performance bottleneck or an abnormal risk exists or not, and determining the relevance between the performance bottleneck or the abnormal risk and a database performance problem. If the risk exists, acquiring a system load sudden change trend and a resource request rate, quantifying a system pressure degree, and inputting a performance optimization model to generate an adaptive tuning strategy; calculating statement complexity through an SQL audit log, and selecting an index adjustment strategy in combination with an index optimization model; evaluating the influence of the tuning strategy and the index strategy on the throughput, the response delay and the resource utilization rate, and determining a target high-performance strategy; according to the scheme, accurate optimization and efficient operation and maintenance of database performance are realized through intelligent analysis and dynamic adjustment and optimization.

Description

Technical Field

[0001] This invention relates to the field of database operation and maintenance technology, and in particular to a database operation and maintenance decision-making method, device and medium based on a large language model. Background Technology

[0002] With the rapid development of digital technologies, databases, as the core infrastructure for data storage and processing, directly impact the continuity of business operations and user experience. Against the backdrop of the widespread adoption of cloud computing, big data, and distributed architectures, databases face increasingly complex business scenarios, with data volumes growing exponentially and access loads exhibiting high-frequency dynamic changes. Traditional database operation and maintenance models relying on manual experience are no longer sufficient to meet the demands for real-time performance, accuracy, and intelligence.

[0003] Traditional database operations and maintenance primarily rely on manual monitoring of system performance metrics, analysis of SQL execution logs, and manual adjustment of configuration parameters to achieve performance optimization. However, this approach has significant drawbacks: First, the complex relationships hidden within massive amounts of monitoring data and log information are difficult to identify quickly manually. For example, analyzing the correlation between slow queries and issues such as missing indexes, lock contention, and transaction blocking depends on the experience of senior administrators, which can easily lead to missed or misjudged potential performance bottlenecks. Second, in the face of sudden load fluctuations, manual response is noticeably delayed, making it impossible to dynamically adjust system parameters in real time to match load changes, potentially leading to increased response latency, decreased throughput, or even service interruptions. Third, the assessment of SQL statement complexity and the formulation of index optimization strategies lack systematic intelligent analysis tools, relying on manual line-by-line auditing of SQL code, which is inefficient and difficult to cover all data operation scenarios.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a database operation and maintenance decision-making method, device, and medium based on a large language model, aiming to solve the technical problem of low efficiency in traditional database operation and maintenance, which mainly relies on manual monitoring of system operation indicators, analysis of SQL execution logs, and manual adjustment of configuration parameters to achieve performance optimization.

[0006] To achieve the above objectives, this invention provides a database operation and maintenance decision-making method based on a large language model, the method comprising: Collect real-time operating metrics and historical log data from the database, and extract multi-dimensional time-series features from the real-time operating metrics and historical log data; Based on the aforementioned multi-dimensional time-series features, a large language model is used to determine whether there are potential performance bottlenecks or anomaly risks, and to determine the correlation between the aforementioned multi-dimensional time-series features and database performance issues. If there are potential performance bottlenecks or abnormal risks, obtain the current system load change trend and resource request rate, obtain system stress data based on the load change trend and resource request rate, input the system stress data into the performance optimization model, and output the adaptive tuning strategy of the database system. The complexity of SQL statements is calculated by using the database SQL audit logs, and the index adjustment strategy of the database system is selected by using a pre-established index optimization model. Evaluate the impact of the adaptive tuning strategy and the index adjustment strategy on the throughput, response latency and resource utilization of the database system, and determine the target high-performance tuning strategy and the target high-performance index strategy. Real-time monitoring of key performance indicator curves and resource usage distribution after the implementation of the target high-performance tuning strategy and the target high-performance indexing strategy, and time series analysis to obtain performance indicator time series data. The performance indicator time series data is divided into samples of a set length, and the load peak rate and performance decay rate of the samples are predicted to obtain prediction results. Based on the prediction results, a continuous optimization scheme for database configuration and indexing strategy is formed.

[0007] Optionally, the real-time operating metrics and historical log data collected from the database are used to extract multi-dimensional time-series features of the real-time operating metrics and historical log data, including: Collect real-time operating metrics and historical log data from the database. Based on the real-time operating metrics and historical log data, obtain SQL execution flow data and system resource counter data. Calculate load balancing parameters based on the SQL execution flow data and system resource counter data to obtain the first operating metric sequence. The first operating index sequence is decomposed into load periodicity using Fast Fourier Transform. If the periodic energy density is higher than the baseline fluctuation threshold, a second operating index sequence is generated. By performing wavelet decomposition on the second operational indicator sequence to obtain short-term fluctuation and long-term trend components, and extracting the connection pool utilization rate change and transaction status persistence characteristic curves from the components, a third operational indicator sequence is obtained. The recursive least squares method is used to fit the sequence of the third operating index to obtain the resource utilization rate change characteristic curve. The high-frequency noise and low-frequency trend of the resource utilization rate change characteristic curve are filtered by the feature selection algorithm to obtain the multi-dimensional time-series features of query frequency data and I / O throughput data.

[0008] Optionally, the step of using a large language model to determine whether there are potential performance bottlenecks or anomaly risks based on the multi-dimensional time-series features, and determining the correlation between the features and database performance issues, includes: Based on the multi-dimensional time-series features, real-time performance indicator streams are obtained from the database monitoring endpoint. Natural language descriptions are then converted from the real-time performance indicator streams using a large language model to obtain descriptive text. Semantic matching calculations are performed on the descriptive text within a preset risk keyword library to obtain matching confidence. First risk feature data is obtained by comparing the matching confidence with a preset confidence threshold. Based on the first risk feature data, anomaly points are extracted from the real-time performance indicator stream, and the change gradient is calculated using a sliding window. If the change gradient is greater than a preset mutation threshold, first performance jitter feature data is generated. The first performance jitter feature data is obtained by context association and root cause feature extraction using an attention mechanism model; The second risk feature data is analyzed using semantic relevance calculation to extract event association features. If the matching degree of the event association features exceeds a preset matching degree threshold, it is determined that the real-time operation indicator is associated with performance disturbances caused by specific application load or configuration changes.

[0009] Optionally, if potential performance bottlenecks or anomaly risks exist, the following steps are taken: obtaining the current system load fluctuation trend and resource request rate; obtaining system stress level data based on the load fluctuation trend and resource request rate; inputting the system stress level data into the performance optimization model; and outputting an adaptive tuning strategy for the database system, including: If there are potential performance bottlenecks or abnormal risks, obtain the current system load change trend and resource request rate from the database monitoring system, and use the change detection algorithm to locate the inflection point of the current system load change trend and resource request rate to obtain system pressure data. Based on the system stress level data and the current available system resources data, multiple linear regression is used to fit the data and obtain the first resource response parameter. The second resource response parameter is obtained by optimizing the first resource response parameter and historical tuning strategy data using a pre-established performance optimization model. The connection pool size adjustment threshold and the worker thread number adjustment parameter are calculated based on the second resource response parameter. The adjustment threshold and response latency parameter are used to construct the tuning strategy matrix to obtain the adaptive tuning strategy of the database system. The adaptive tuning strategy includes determining the memory allocation, concurrency control parameters and the speed of response load changes of the database system.

[0010] Optionally, after calculating the connection pool size adjustment threshold and worker thread number adjustment parameter based on the second resource response parameter, and constructing an optimization strategy matrix using the adjustment threshold and response latency parameter to obtain the adaptive optimization strategy of the database system, the method further includes: Obtain the current memory usage, CPU utilization, and buffer hit rate of the database system, and construct a performance target function based on preset peak business periods and historical performance baselines; Set target response time and target resource utilization as constraints, and use gradient descent algorithm to solve the performance objective function under the constraints to obtain a set of candidate optimization strategies; The adaptive tuning strategy is obtained by selecting the tuning strategies in the candidate tuning strategy set whose expected improvement exceeds the preset performance threshold.

[0011] Optionally, the step of calculating the SQL statement complexity through the database SQL audit log and selecting the database system's index adjustment strategy through a pre-established index optimization model includes: Obtain a set of slow query statements from the database SQL audit logs, and obtain the first SQL complexity data by parsing the slow query statement set and extracting its features. An index status analysis was performed on the data tables involved in the set of slow query statements. A cost model was used to calculate the potential benefits of missing indexes, and the first index missingness data was obtained. Based on the joint evaluation of the first SQL complexity data and the first index missingness data, the recommended index fields and types are determined by query optimizer simulation, and the first index recommendation data and the first index adjustment data are obtained. An assessment of the impact of storage space and write performance on the first index recommended data and the first index adjusted data is conducted. The recommended parameters are constrained and verified using a preset index optimization model to select the index adjustment strategy for the database system.

[0012] Optionally, evaluating the impact of the adaptive tuning strategy and the index adjustment strategy on the throughput, response latency, and resource utilization of the database system, and determining the target high-performance tuning strategy and the target high-performance indexing strategy, includes: Obtain baseline data of throughput and average response latency before the implementation of the adaptive tuning strategy and the index adjustment strategy in the database monitoring system, and obtain first evaluation data by performing performance profiling on the baseline data through time series analysis. Based on the first evaluation data, the database operation data after the implementation of the adaptive tuning strategy and the index adjustment strategy is collected, and the second evaluation data is obtained by statistical analysis to calculate the percentage change in throughput and the percentage reduction in response latency. The changes in CPU and memory resource utilization are calculated based on the second evaluation data, and the third evaluation data is obtained through the resource efficiency model. The performance benefit calculator is used to comprehensively calculate the second evaluation data and the third evaluation data. Based on the business weight, the throughput improvement and latency reduction are weighted to obtain the comprehensive strategy benefit data. If the overall benefit data of the strategy shows that the throughput is higher than the benchmark value and the response latency is lower than the benchmark value, then the current tuning and indexing strategy is determined as the target high-performance tuning strategy and the target high-performance indexing strategy.

[0013] Optionally, the real-time monitoring of key performance indicator curves and resource usage distribution after the implementation of the target high-performance tuning strategy and the target high-performance indexing strategy, and the performance indicator time series data, is performed to obtain performance indicator time series data. This performance indicator time series data is then divided into samples of a set length, and the peak load rate and performance degradation rate of the samples are predicted to obtain prediction results. Based on these prediction results, a continuous optimization scheme for the database configuration and indexing strategy is formed, including: The key performance indicator curves and resource usage distribution after the implementation of the target high-performance tuning strategy and the target high-performance indexing strategy are decomposed by spectrum analysis, and the first load mode data is calculated based on the periodic characteristics. Real-time performance metrics are calculated for the first load mode data, and the metric curve is segmented using a sliding window to obtain the first performance time series data. Based on the first performance time series data, the samples are divided, and key indicators are extracted from the divided sample segments to obtain the second performance time series data. A long short-term memory network is trained on the second performance time series data to extract load change and performance degradation features from historical data and obtain the first prediction parameters. The first prediction parameter is used to calculate the peak load rate and performance degradation rate, and the second prediction parameter is obtained by judging through a threshold comparator. If the peak load rate or performance degradation rate exceeds the preset safety threshold, the current performance status data is recorded, and a configuration adjustment suggestion is generated based on the predicted deviation magnitude to obtain continuous database optimization parameters. Based on the continuous database optimization parameters, a continuous optimization scheme for database configuration and indexing strategies is obtained.

[0014] Furthermore, to achieve the above objectives, the present invention also provides a database operation and maintenance decision-making device based on a large language model. The device includes: a memory, a processor, and a database operation and maintenance decision-making program based on a large language model stored in the memory and executable on the processor. The database operation and maintenance decision-making program based on a large language model is configured to implement the steps of the database operation and maintenance decision-making method based on a large language model as described above.

[0015] In addition, to achieve the above objectives, the present invention also provides a storage medium storing a database operation and maintenance decision program based on a large language model, wherein when the database operation and maintenance decision program based on a large language model is executed by a processor, it implements the steps of the database operation and maintenance decision method based on a large language model as described above.

[0016] This invention provides a database operation and maintenance decision-making method based on a large language model. The method collects real-time operation indicators and historical log data, extracts multi-dimensional time-series features, and combines the deep parsing capabilities of the large language model for log text and SQL semantics. This can overcome the limitations of traditional threshold monitoring and identify progressive performance bottlenecks and hidden anomaly risks in advance. Compared to human experience or simple machine learning models, this method has stronger reasoning capabilities for complex correlation features, enabling an upgrade from single-point indicator alerts to "multimodal data correlation diagnosis," reducing missed and false positive rates. For sudden changes in system load, the solution analyzes load trends and resource request rates to quantify system stress levels and inputs them into a performance optimization model, generating real-time dynamic tuning strategies. Traditional manual tuning relies on static experience, making it difficult to match real-time load fluctuations. This solution, through an automated link from stress perception to strategy generation, can complete parameter adaptation within milliseconds, significantly improving database throughput and response stability in high-concurrency scenarios and avoiding service degradation risks due to configuration lag. By parsing SQL audit logs to calculate statement complexity and combining it with an index optimization model to dynamically select index adjustment strategies, it changes the inefficient traditional manual line-by-line SQL auditing model. This module can automatically identify problems such as storage bloat caused by redundant indexes and full table scans caused by missing indexes, generating strategies tailored to different business scenarios. This differentiated strategy reduces DBA maintenance costs while improving SQL execution efficiency by 30%-50%, making it particularly suitable for complex business systems with high-frequency read / write operations. The solution comprehensively evaluates multiple dimensions of metrics, including throughput, response latency, and resource utilization, to select high-performance strategies from candidate strategies, avoiding global performance imbalances caused by single-dimensional optimization. Traditional methods often rely on single-point tuning, while this solution establishes a multi-objective optimization model to achieve a dynamic balance between resource allocation and business objectives, ensuring the database maintains low latency, high availability, and efficient resource utilization even under high load. By monitoring key indicator curves after strategy implementation in real time, segmenting time-series samples, and predicting peak load rates and performance degradation rates, a proactive optimization plan is formed. This mechanism can proactively identify issues such as strategy failures caused by periodic load fluctuations and performance degradation caused by long-term operation. For example, it can predict the impact of batch tasks on disk I / O in the early morning and pre-adjust parameters, avoiding post-fault repair delays in traditional passive response modes. Attached Figure Description

[0017] Figure 1This is a schematic diagram of the hardware operating environment of the database operation and maintenance decision-making device based on a large language model involved in the embodiments of the present invention; Figure 2 This is a flowchart illustrating the first embodiment of the database operation and maintenance decision-making method based on a large language model according to the present invention. Figure 3 This is a structural block diagram of the first embodiment of the database operation and maintenance decision system based on a large language model according to the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0020] Reference Figure 1 , Figure 1 This is a schematic diagram of the structure of a database operation and maintenance decision-making device based on a large language model, which is part of the hardware operating environment involved in the embodiments of the present invention.

[0021] like Figure 1 As shown, the database operation and maintenance decision-making device based on a large language model may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen, and optionally, it may also include a standard wired interface or a wireless interface. In this invention, the wired interface of the user interface 1003 may be a USB interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a non-volatile memory (NVM), such as a disk storage device. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0022] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on database operation and maintenance decision-making equipment based on large language models. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0023] like Figure 1As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a database operation and maintenance decision-making program based on a large language model.

[0024] exist Figure 1 In the database operation and maintenance decision-making device based on a large language model shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to peripherals; the database operation and maintenance decision-making device based on a large language model calls the database operation and maintenance decision-making program based on a large language model stored in the memory 1005 through the processor 1001, and executes the database operation and maintenance decision-making method based on a large language model provided in the embodiment of the present invention.

[0025] Based on the above hardware structure, an embodiment of the database operation and maintenance decision-making method based on a large language model of the present invention is proposed.

[0026] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the database operation and maintenance decision-making method based on a large language model according to the present invention. The first embodiment of the database operation and maintenance decision-making method based on a large language model according to the present invention is presented.

[0027] In the first embodiment, the database operation and maintenance decision-making method based on a large language model includes the following steps: Step S100: Collect real-time operating metrics and historical log data from the database, and extract multi-dimensional time-series features from the real-time operating metrics and historical log data.

[0028] Real-time operational metrics can be performance parameters generated during database operation, including but not limited to CPU utilization, memory usage, disk I / O throughput, network latency, and transaction processing rate. These can be obtained in real time through database monitoring tools or built-in interfaces. Historical log data can be operational information recorded by the database over a long period, including but not limited to SQL execution logs, error logs, and transaction logs. These can be extracted through a log storage system. Multi-dimensional time-series features can be a set of parameters extracted from the above data using time-series analysis methods, such as the fluctuation range of the metrics, the rate of change of trends, periodic patterns, and outlier distribution. These can be achieved through techniques such as sliding window statistics, Fourier transform, and wavelet decomposition. The technical operation includes three sub-processes: data acquisition, preprocessing, and feature extraction. First, raw data is collected through monitoring tools or interfaces. Then, noisy data is cleaned, timestamps are aligned, missing values ​​are processed, and the text logs are converted into structured features using natural language processing techniques (such as word segmentation and entity recognition). Finally, time-series analysis algorithms (such as ARIMA and LSTM) are used to capture the changing patterns of the metrics and combine them with log keywords to generate composite features. This process provides multi-dimensional input for subsequent analysis by constructing a comprehensive set of time-series features.

[0029] Step S200: Based on multi-dimensional time-series features, use a large language model to determine whether there are potential performance bottlenecks or abnormal risks, and determine the correlation between multi-dimensional time-series features and database performance issues.

[0030] Large language models can be pre-trained models with contextual understanding capabilities, such as GPT or BERT, capable of analyzing multimodal data through joint modeling. Performance bottlenecks can be scenarios where processing power is reduced due to resource constraints, such as full table scans caused by missing indexes or transaction blocking caused by lock contention. Correlation can be a causal or related relationship between features and performance issues, such as the correlation between a sudden drop in CPU utilization and an increase in disk I / O latency. Technical operations include feature encoding, model inference, and association rule generation: first, temporal features are encoded into numerical vectors or text word embeddings; then, anomaly patterns, such as index mutations or high-frequency error codes, are identified through multi-layer neural networks of the large language model; finally, causal inference is performed by combining prior knowledge bases (such as known cases). This process, through multimodal data association analysis, overcomes the limitations of traditional threshold alerts and reduces the missed detection rate of hidden problems.

[0031] Step S300: If there are potential performance bottlenecks or abnormal risks, obtain the current system load change trend and resource request rate, obtain system stress level data based on the load change trend and resource request rate, input the system stress level data into the performance optimization model, and output the adaptive tuning strategy of the database system.

[0032] Load fluctuation trends can be drastic changes in system load within a short period, such as sudden high-concurrency requests or traffic spikes caused by periodic tasks. The magnitude and duration of these fluctuations can be analyzed using time series forecasting algorithms (such as Prophet and LSTM). Resource request rate can be the number of requests a user or application makes to database resources per unit of time, such as queries per second. System stress level data can be quantified stress indicators, such as those generated by combining resource utilization and load growth rate through weighted scoring or cluster analysis. Performance optimization models can be machine learning or rule engine-based models, such as reinforcement learning or decision trees. These models output tuning strategies based on input stress data, such as dynamically adjusting buffer size or thread pool size. The technical operations include three sub-processes: load analysis, stress quantification, and strategy generation. By responding to load changes in real time, the tuning strategies are output in milliseconds, improving throughput stability in high-concurrency scenarios.

[0033] Specifically, the process of establishing the performance optimization model includes: Input design is based on system stress data as the core input, including current system load fluctuation trends (such as CPU / memory / disk I / O utilization fluctuation curves, and the sudden increase rate of concurrent connections) and resource request rates (such as transaction requests per second (TPS), and query response time percentile values). This multi-dimensional data needs to be transformed into structured feature vectors. The output is the adaptive tuning strategy for the database system, specifically including a set of executable configuration parameters such as connection pool parameter adjustments (such as maximum number of connections and timeout), buffer size configuration, query optimizer parameter tuning, and locking mechanism optimization strategies. The optimization objective is a multi-objective optimization function that maximizes throughput, minimizes response latency, and balances resource utilization. For example, a comprehensive loss function is constructed that includes throughput weights, latency penalties, and resource overload coefficients. Data on strategies and their implementation effects from historical operations and maintenance, such as the latency reduction after adjusting connection pool parameters during a CPU overload, is collected and combined with real-time operational metrics to construct a training dataset. Simulate different load surge scenarios, such as sudden traffic spikes and slow query storms, using load testing tools to record corresponding system pressure characteristics and optimal tuning strategies, thus expanding the training samples for edge scenarios. Combine real-time metrics (such as current QPS and cache hit rate) with historical baseline data (such as the average load curve over the past 7 days) to calculate derived features such as pressure deviation and resource bottleneck coefficients, enhancing the model's ability to identify abnormal loads. Considering the dynamic mapping relationship between system pressure and tuning strategies, reinforcement learning models (such as Deep Q-Network (DQN) and policy gradient algorithms) or hybrid models combining time-series prediction and decision trees can be used: reinforcement learning can simulate the tuning process, iteratively optimizing the strategy generation logic through a closed-loop process from policy implementation to performance feedback, adapting to the sequential dependencies of the load; time-series models (such as LSTM and Transformer) can first predict load trends and then combine them with decision models to generate parameter configurations that match the current pressure. The training process uses historical tuning effect data as a supervision signal, initializing model parameters through supervised learning; then, it continuously updates through online learning in a real-time operation and maintenance environment, enabling the model to adapt to the time-varying nature of database load, such as business peak and valley cycles.

[0034] Furthermore, the performance optimization model includes a feasible strategy space definition: pre-setting safety thresholds for tuning parameters, such as ensuring the connection pool size does not exceed database kernel limits and buffer memory does not exceed 80% of physical memory, to avoid aggressive strategies that could cause system crashes due to model generation. Before the model outputs a strategy, a manual rule verification layer is added. For example, when CPU utilization consistently exceeds 95%, a rate-limiting strategy is triggered first, rather than simply tuning parameters, ensuring the safety and reliability of automated decision-making. Historical failure scenarios are reviewed to verify the effectiveness of the model's strategies under known stress conditions, such as comparing the performance recovery time of model-generated strategies with manually optimized strategies. The model is gradually deployed to non-core business databases in the production environment. By comparing key metrics of the experimental group (model tuning) and the control group (rule tuning), such as the average response time reduction rate, model parameters and objective function weights are continuously optimized.

[0035] Step S400: The complexity of the SQL statement is calculated through the database SQL audit log, and the index adjustment strategy of the database system is selected through the pre-established index optimization model.

[0036] SQL audit logs can be log files that record information such as SQL statement execution time, execution plan, and number of returned rows. SQL statement complexity can be a quantitative indicator evaluated through dimensions such as syntax structure, execution plan, and resource consumption; for example, it can be calculated using syntax analysis tools by multiplying the number of JOINs by the execution time. Index optimization models can be rule-based or machine learning-based models, such as cost models or supervised learning models, used to identify missing or redundant indexes. The technical operation includes three sub-processes: log parsing, complexity calculation, and strategy generation. First, the audit logs are parsed to extract the execution plan and performance metrics; then, the complexity score is calculated; and finally, index optimization suggestions for high-frequency queries are identified using the index optimization model. This process automates analysis to replace manual auditing, reducing the storage overhead of redundant indexes and improving query efficiency.

[0037] Step S500: Evaluate the impact of adaptive tuning strategies and index adjustment strategies on the throughput, response latency, and resource utilization of the database system, and determine the target high-performance tuning strategy and the target high-performance index strategy.

[0038] Throughput can be the number of transactions or queries processed per unit of time; response latency can be the time interval between a request and a result; and resource utilization can be the ratio of the actual utilization of resources such as CPU, memory, and disk to their maximum capacity. Multi-objective optimization models can be mathematical models that seek a balance between throughput, latency, and resource utilization, such as Pareto optimality or genetic algorithms. The technical operation includes three sub-processes: strategy simulation, multi-objective evaluation, and strategy selection. First, candidate strategies are simulated using load testing tools or simulators to collect performance data; then, a comprehensive score of the strategies is calculated using weighted summation or constrained optimization methods; finally, the strategy combination with the highest score is selected as the target strategy. This process avoids global performance imbalances caused by single-point optimization, such as memory overflow problems caused by increased throughput.

[0039] Step S600: Monitor the key performance indicator curves and resource usage distribution after the implementation of the target high-performance tuning strategy and the target high-performance indexing strategy in real time, and perform time series analysis to obtain performance indicator time series data. Divide the performance indicator time series data into samples of a set length, predict the peak load rate and performance decay rate of the samples, obtain the prediction results, and form a continuous optimization plan for database configuration and indexing strategy based on the prediction results.

[0040] Key performance indicator (KPI) curves can be visualizations of how core metrics such as QPS and latency change over time. Peak load rate can be the frequency or proportion of load reaching its peak per unit time, and performance degradation rate can be the rate at which metrics deteriorate over time, such as a 5% decrease in throughput per week. Continuous optimization solutions can be dynamically adjusted strategies and update plans based on prediction results, such as proactive scaling up or index rebuilding. The technical operation includes four sub-processes: data acquisition, time series segmentation, predictive modeling, and solution generation. First, post-implementation KPI data is collected in real-time. Then, time series are segmented using a sliding window. Next, time series prediction algorithms or deep learning models are used to predict future trends. Finally, automated adjustment suggestions are generated based on the prediction results. This process reduces latency caused by reactive responses through proactive optimization.

[0041] This embodiment provides a database operation and maintenance decision-making method based on a large language model. It collects real-time operational metrics and historical log data, extracts multi-dimensional time-series features, analyzes the correlation between features and performance issues using a large language model, generates adaptive tuning strategies by combining load mutation trends and resource request rates, calculates index adjustment strategies using SQL audit logs to assess complexity, evaluates the impact of multiple strategies on throughput, latency, and resource utilization to determine the target strategy, and finally forms a continuous optimization plan through real-time monitoring and prediction. This achieves technical effects that overcome the limitations of traditional manual operation and maintenance. Specifically, it: accurately identifies hidden performance bottlenecks through multi-modal data joint analysis, reducing the false positive rate; shortens configuration adjustment time to milliseconds based on a rapid response mechanism for load mutations; reduces redundant storage overhead through automated index optimization; avoids global imbalance caused by single-point optimization through multi-objective evaluation; and enables proactive operation and maintenance through forward-looking prediction, reducing the risk of failure delays.

[0042] In one embodiment, real-time operating metrics and historical log data of the database are collected, and multi-dimensional time-series features of the real-time operating metrics and historical log data are extracted, including: Collect real-time operating metrics and historical log data from the database. Based on the real-time operating metrics and historical log data, obtain SQL execution flow data and system resource counter data. Calculate the load balancing parameters based on the SQL execution flow data and system resource counter data to obtain the first operating metric sequence. Real-time performance metrics can be instantaneous performance parameters of database nodes or instances, such as CPU core utilization and memory page fault rate, which can be obtained through database monitoring tools or system kernel interfaces. Historical log data can be a stream of records that document SQL execution time, resource consumption, etc., including, but not limited to, fields such as SQL execution timestamp, query type, and number of rows returned. SQL execution stream data can be a structured log that records detailed business operations, such as the execution time of each SQL statement and lock wait time. System resource counter data can be statistical metrics maintained by the operating system or database kernel, such as memory allocation deviation rate and disk I / O operation count. Load balancing parameters can be metrics that quantify the load differences between nodes, including, for example, CPU utilization standard deviation and memory allocation deviation rate, used to identify potential performance bottlenecks caused by uneven resource allocation.

[0043] By aggregating SQL execution pipeline data and system resource counter data according to time windows and calculating the load difference index of each node, a first operational index sequence can be generated. In one specific embodiment, this process forms a time series containing multi-dimensional load differences by statistically analyzing the standard deviation of CPU utilization and the memory allocation deviation rate within a preset time window. The technical effect of this operation is to quantify the balance of resource allocation within the database cluster, providing quantifiable benchmark data for subsequent analysis.

[0044] The load periodicity is decomposed by Fast Fourier Transform for the first operating index sequence. If the periodic energy density is higher than the baseline fluctuation threshold, the second operating index sequence is generated. The Fast Fourier Transform (FFT) is a mathematical method that converts a time-domain signal into a frequency-domain representation, used to identify periodic fluctuation patterns. Periodic energy density can be the proportion of energy at a specific frequency component in the frequency domain, exemplarily obtained by calculating the ratio of the square of the amplitude of a specific frequency component to the total energy. The baseline fluctuation threshold can be the average fluctuation value obtained from historical data, such as calculating the average energy density over the past week using a sliding window.

[0045] By inputting the first operational index sequence into a Fast Fourier Transform algorithm, periodic components are separated and their energy densities are calculated. If the energy density of a certain frequency component exceeds a preset threshold, a significant periodic load pattern is identified, and this sequence is marked as the second operational index sequence. The technical advantage of this operation is that it distinguishes between random fluctuations and regular periodic patterns, avoiding misjudging periodic loads as sudden abnormal events, thereby improving the accuracy of subsequent analysis.

[0046] By performing wavelet decomposition on the second operational indicator sequence to obtain short-term fluctuation and long-term trend components, and extracting the change in connection pool utilization and the characteristic curve of transaction status persistence from the components, the third operational indicator sequence is obtained. Wavelet decomposition can be a time-frequency analysis method that decomposes a signal into components of different scales, exemplified by Haar wavelets or Daubechies wavelet basis functions. Short-term fluctuation components can be high-frequency components reflecting sudden changes in connection pool utilization, such as the growth rate of connections per unit time. Long-term trend components can be low-frequency components reflecting the persistence characteristics of transaction states, such as the cumulative duration of uncommitted transactions. The transaction state persistence characteristic curve can be a smooth curve describing the change in transaction blocking time over time.

[0047] By selecting appropriate wavelet basis functions to perform multi-scale decomposition on the second operational indicator sequence, high-frequency and low-frequency components are separated. Then, the connection pool utilization change is extracted from the high-frequency components, and the transaction status persistence characteristic curve is extracted from the low-frequency components, forming a third operational indicator sequence containing multi-scale features. The technical advantage of this operation is that it simultaneously captures sudden anomalies and gradual risks, such as abnormal patterns at different time scales like connection pool exhaustion or memory leaks.

[0048] The recursive least squares method is used to fit the sequence of the third operating index to obtain the characteristic curve of resource utilization rate change. The high-frequency noise and low-frequency trend of the characteristic curve of resource utilization rate change are filtered by the feature selection algorithm to obtain the multi-dimensional time-series features of query frequency data and I / O throughput data.

[0049] Recursive least squares can be an adaptive filtering algorithm that updates parameters online, for example, updating weight coefficients through iterative formulas to approximate the true trend. Resource utilization change characteristic curves can be smooth curves describing the changes in indicators such as CPU utilization and memory usage over time. Feature selection algorithms can be dimensionality reduction methods based on variance thresholding or principal component analysis, for example, filtering key features through information gain.

[0050] The third operational indicator sequence is dynamically fitted using recursive least squares to generate a real-time curve of resource utilization. Feature selection algorithms are then applied, such as setting a variance threshold to remove instantaneous fluctuations or using principal component analysis to retain long-term trend components. The final extracted query frequency data can represent the long-term trend of queries per second, and the I / O throughput data can represent the periodic fluctuations in disk read / write rates. The technical effect of this operation is to improve the signal-to-noise ratio of the features and enhance the model's ability to identify long-term trends and periodic patterns.

[0051] This embodiment quantifies resource allocation differences by collecting real-time operational metrics and historical log data and calculating load balancing parameters. It uses Fast Fourier Transform to distinguish between periodic loads and random fluctuations, combines wavelet decomposition to separate multi-scale features, and then employs recursive least squares and feature selection algorithms to achieve noise suppression and trend enhancement, ultimately forming time-series features including query frequency and I / O throughput. This method, by introducing a combination of professional algorithms from the field of signal processing, achieves accurate multi-scale identification of database performance anomalies. It can capture both sudden resource exhaustion events and monitor gradual resource leakage risks. Simultaneously, dynamic filtering technology improves the reliability of feature data, providing a high-quality input foundation for subsequent correlation analysis of large language models and generation of operation and maintenance strategies, significantly enhancing the accuracy and robustness of database operation and maintenance decisions.

[0052] In one embodiment, based on multi-dimensional temporal features, a large language model is used to determine whether there are potential performance bottlenecks or anomaly risks, and to determine the correlation between features and database performance issues, including: Based on multi-dimensional time-series features, real-time performance indicator streams are obtained from database monitoring endpoints. Natural language descriptions are then converted from the real-time performance indicator streams using a large language model to obtain descriptive text. Semantic matching calculations are performed on the descriptive text within a preset risk keyword library to obtain matching confidence. The first risk feature data is obtained by comparing the matching confidence with a preset confidence threshold. Natural language description transformation can be the process of converting structured performance metric data into understandable natural language text. This can be achieved through predefined templates or generative models, such as transforming "CPU utilization 90%" into "CPU utilization consistently exceeds the threshold". The risk keyword library can be a collection of predefined performance anomaly terms, built using domain knowledge or historical cases and dynamically expandable. Examples include terms like "lock wait" and "full table scan". Match confidence is a quantified value of the degree of match between the description text and terms in the risk keyword library, typically calculated using TFIDF or the BERT model.

[0053] This process is achieved through three sub-steps: indicator stream parsing, text generation, and semantic matching. First, real-time performance indicators are parsed into structured values. Then, they are transformed into natural language descriptions through template filling or generation models. Finally, semantic matching calculations are performed with a risk keyword library, thereby achieving the technical effect of transforming abstract indicators into analyzable text.

[0054] Anomalies are extracted from the real-time performance indicator stream based on the first risk feature data. The change gradient is calculated using a sliding window. If the change gradient is greater than the preset mutation threshold, the first performance jitter feature data is generated. The sliding window can be a fixed-length time interval used to divide time series data, such as a 5-minute interval window. The gradient of change can be a quantified value of the rate of change of the indicator value within the window, such as the percentage change in CPU utilization from 60% to 95%.

[0055] This process is achieved through three sub-steps: window division, gradient calculation, and threshold judgment. First, the indicator flow is divided into time windows, the rate of change of the indicators within the window is calculated, and then compared with a preset threshold, thereby achieving the technical effect of accurately locating the moment of indicator mutation.

[0056] The second risk feature data is obtained by performing context association and root cause feature extraction on the first performance jitter feature data through an attention mechanism model; The attention mechanism model can be a neural network component that highlights key contextual information through weight allocation, such as the self-attention mechanism in Transformer. Root cause features can be features that are strongly correlated with outliers and are potential sources of problems, such as the co-occurrence pattern of thread blocking events and sudden increases in CPU utilization.

[0057] This process is achieved through three sub-steps: time series encoding, weight calculation, and feature selection. First, the data before and after the outlier is encoded, the association weight between each time step and the outlier is calculated, and the feature with the highest weight is extracted as the root cause candidate, thereby achieving the technical effect of narrowing down the scope of the problem.

[0058] Semantic relevance calculation is used to analyze the second risk feature data and extract event association features. If the matching degree of the event association features exceeds the preset matching degree threshold, it is determined that the real-time operation indicators are associated with the performance disturbance caused by specific application load or configuration changes.

[0059] Semantic relevance calculation can be a method for quantifying the semantic similarity of text fragments, such as the vector space model or the BERT model. Event association features can be identifiers of potential causal relationships between anomalies in indicators and external events, such as the semantic matching results of "connection pool exhaustion" and "application concurrency surge".

[0060] This process is achieved through three sub-steps: feature vectorization, similarity calculation, and threshold comparison. First, the root cause features and the preset event types are converted into semantic vectors, and the similarity between the two is calculated. Then, it is compared with the threshold, thereby achieving the technical effect of establishing a direct link between indicator anomalies and external events.

[0061] This embodiment converts structured indicators into natural language text and combines it with a risk keyword database for initial risk localization. It utilizes sliding windows and gradient analysis for mutation detection, leverages attention mechanisms to mine contextual features, and finally establishes a causal relationship between indicator anomalies and external events through semantic relevance calculation. This achieves the technical effects of improving risk localization accuracy, accelerating mutation response speed, deepening root cause analysis, and enhancing the reliability of event attribution. Through multi-stage collaborative operation of textual analysis, mutation detection, contextual correlation, and semantic attribution, this method upgrades traditional indicator alerts to automated root cause reasoning, significantly reducing manual investigation costs and improving the credibility of operational decisions.

[0062] In one embodiment, if a potential performance bottleneck or anomaly risk exists, the current system load fluctuation trend and resource request rate are obtained. Based on the load fluctuation trend and resource request rate, system stress level data is obtained. The system stress level data is input into the performance optimization model, and an adaptive tuning strategy for the database system is output, including: If there are potential performance bottlenecks or abnormal risks, obtain the current system load change trend and resource request rate from the database monitoring system, and use the change detection algorithm to locate the inflection point of the current system load change trend and resource request rate to obtain system pressure data. The system load abrupt change trend can be the dynamic trajectory of system resource utilization or request volume in a time series. This can be obtained through real-time data collected by database monitoring tools, such as CPU utilization, memory usage, and transaction throughput. For example, the system load abrupt change trend could include a curve showing a sudden jump in CPU utilization from 30% to 80% within 10 seconds. The resource request rate can be the number of query or transaction requests received by the database per unit time. This can be obtained through metrics such as query per second (QPS) or transaction processing per second (TPS) monitored by the monitoring system. For example, the resource request rate could include a sudden increase in the number of new requests per second from 500 to 2000. The abrupt change detection algorithm can be an algorithm used to identify significant change points in a time series, including but not limited to cumulative sum control charts (CUSUM), sliding window statistics, or methods based on statistical hypothesis testing (such as the Pettit test). For example, sliding window statistics can locate inflection points by calculating the standard deviation change of the data within the window. Inflection point location can be achieved by using mutation detection algorithms to identify turning points in load mutations within a time series, such as the moment of a sudden jump from a stable state or the critical point of a gradual decline from a peak. For example, this process can employ Dynamic Time Warping (DTW) or cluster analysis to divide mutation intervals. System stress level data can be a set of parameters quantifying mutation characteristics, including mutation rate, mutation magnitude, duration, and the number of times resource utilization thresholds are exceeded. For example, system stress level data can include records of CPU utilization mutations reaching 50% and lasting for more than 15 seconds.

[0063] Inflection point location can be achieved by using mutation detection algorithms. For example, the difference between the local mean and the global mean of a time series can be calculated by using a sliding window. When the difference exceeds a preset threshold, it is determined to be a mutation point, thereby achieving the technical effect of accurately identifying the starting point or peak inflection point of load mutation.

[0064] Based on the system stress level data and the current available system resources data, multiple linear regression is used to fit the data and obtain the first resource response parameter; The available system resource data can be the current unused resource capacity of the database system, including remaining memory, number of idle threads, and unused cache space. For example, the available system resource data could include 200 currently idle threads. Multiple linear regression can be a statistical model that predicts a dependent variable using multiple independent variables. For example, this model could use the mutation rate and peak resource request as independent variables, and historical performance indicators (such as response latency and throughput) as dependent variables to establish a predictive relationship. The first resource response parameter can be the set of parameters output by the multiple linear regression model, reflecting the system resource response to load changes. For example, the first resource response parameter could include the linear correlation coefficient between CPU utilization and QPS, and the regression coefficient between memory latency and transaction throughput.

[0065] Data fitting can be achieved by using multiple linear regression. For example, the regression coefficients can be estimated using the least squares method. By inputting stress data and available resource data as independent variables into the model, the technical effect of quantifying resource response characteristics can be achieved.

[0066] The second resource response parameter is obtained by optimizing the first resource response parameter and historical tuning strategy data using a pre-established performance optimization model. The historical tuning strategy data can be records of past tuning operations and their corresponding performance feedback, including correlation data between adjusted parameter values ​​and changes in system response latency and throughput. For example, historical tuning strategy data could include records of "a 20% increase in the number of threads leading to increased lock contention." The performance optimization model can be a computational framework combining historical data and real-time parameters, including but not limited to reinforcement learning (such as Q-learning) or genetic algorithms. For example, a reinforcement learning model can adjust parameter weights by maximizing the throughput-to-latency ratio through a reward function. The second resource response parameters can be an optimized set of parameters. For example, the second resource response parameters could include suggestions for reducing the cache size when memory pressure increases.

[0067] Optimization calculations can be performed using performance optimization models. For example, Q-learning can be used to simulate the system response under different parameter combinations. By iteratively adjusting the parameter weights to adapt to the current load characteristics, the technical effect of improving the dynamic adaptability of parameters can be achieved.

[0068] The connection pool size adjustment threshold and worker thread number adjustment parameter are calculated based on the second resource response parameter. The tuning strategy matrix is ​​constructed using the adjustment threshold and response latency parameter to obtain the adaptive tuning strategy of the database system. The adaptive tuning strategy includes determining the memory allocation, concurrency control parameters and the speed of response load changes of the database system.

[0069] The connection pool size adjustment threshold can be a critical value at which the connection pool capacity needs to be expanded or shrunk. For example, this threshold can be 1.5 times the current connection pool capacity. The worker thread number adjustment parameter can be a percentage or absolute value of the increase or decrease in the number of threads. For example, this parameter can be that the number of threads needs to be increased by 20%. The tuning strategy matrix can be a two-dimensional mapping table of parameter combinations and expected performance indicators. For example, the matrix cells can contain the predicted latency values ​​corresponding to "20% increase in the number of threads + connection pool expansion". The response latency parameter can be the expected system response time under different parameter combinations. For example, the response latency parameter can include a predicted value that the average transaction latency will be reduced by 15ms after adjustment.

[0070] By constructing a tuning strategy matrix, for example, the performance of each parameter combination can be verified through simulation. For instance, it can be verified whether "increasing the number of threads by 20% + expanding the connection pool" will lead to increased lock contention. This allows for the selection of the globally optimal strategy, thereby achieving the technical effect of avoiding chain reactions caused by adjusting a single parameter.

[0071] This embodiment acquires real-time load fluctuation trends and resource request rates from a database monitoring system, and uses a mutation detection algorithm to accurately locate inflection points to quantify system stress. It establishes resource response parameters using a multiple linear regression model combined with available resource data, and then generates dynamic adjustment parameters based on historical optimization data and the optimization model. Finally, it constructs an optimization strategy matrix through a systematic evaluation of parameter combinations, thereby achieving the technical effects of improving system stress identification accuracy, realizing intelligent resource allocation, and enhancing the global adaptability of optimization strategies. This method, through multi-stage collaborative optimization, effectively reduces the false positive rate, lowers resource waste, and can increase throughput by 15% to 25% in scenarios with sudden traffic surges.

[0072] In one embodiment, after calculating the connection pool size adjustment threshold and worker thread number adjustment parameter based on the second resource response parameter, and constructing an optimization strategy matrix using the adjustment threshold and response latency parameter to obtain the adaptive optimization strategy of the database system, the method further includes: obtaining the current memory usage, CPU utilization, and buffer hit rate of the database system, and constructing a performance objective function by combining preset business peak periods and historical performance baselines; setting target response time and target resource utilization as constraints, and solving the performance objective function under the constraints using a gradient descent algorithm to obtain a candidate optimization strategy set; and selecting optimization strategies in the candidate optimization strategy set whose expected improvement exceeds the preset performance threshold to obtain the adaptive optimization strategy.

[0073] The performance objective function can be a mathematical expression that quantifies the database performance optimization goal, typically including metrics to be maximized or minimized along with weighting coefficients. For example, the performance objective function can include a weighted combination of core metrics such as throughput, response latency, and resource utilization, such as defined as Maximize(α×Throughput+β×ResourceUtilizationγ×Latency), where α, β, and γ are dynamically adjusted weighting parameters. Current memory usage, CPU utilization, and buffer hit rate can be collected in real time by system monitoring tools. For example, memory usage can be provided by the operating system kernel statistics module, and buffer hit rate can be calculated by the database log analysis module. Peak business periods can be preset specific time intervals, such as the batch task period from 00:00 to 02:00 daily. Historical performance baselines can be a set of average performance metrics obtained from long-term operational data statistics, such as the throughput distribution or CPU utilization fluctuation range over the past 30 days.

[0074] The target response time and target resource utilization can be hard constraints imposed on the optimization process. For example, the target response time can be set to ≤100ms, and the target CPU utilization can be set to ≤90%. The gradient descent algorithm can be an iterative optimization method that adjusts parameter values ​​by calculating the gradient direction of the objective function to gradually approach the optimal solution. For example, under constraints, this algorithm may use the Lagrange multiplier method to handle boundary conditions. For instance, when the calculated number of threads exceeds the number of CPU cores, gradient projection is used to ensure that the parameter values ​​remain within the feasible region. The candidate tuning strategy set can be a collection containing multiple feasible parameter combinations. Each strategy includes specific configuration parameters such as connection pool size and number of worker threads. For example, this set can be generated by an algorithm to produce a strategy list containing dozens of parameter combinations, with each strategy corresponding to a set of parameter values ​​and expected performance metrics.

[0075] The preset performance threshold can be a baseline value used to filter candidate strategies. For example, it can be set to an expected throughput increase of ≥15% or a latency reduction of ≥10%. The filtering mechanism can be a filtering process based on performance baseline comparison. For example, if the current throughput is 1000 QPS, only strategies with a predicted value of ≥1150 QPS are retained. This process may use Monte Carlo simulation or A / B testing to verify the effectiveness of the strategy, for example, by simulating the system behavior after the strategy is implemented to eliminate false optimization suggestions caused by model errors.

[0076] In terms of technical operation, when constructing the performance objective function, real-time data and historical baselines need to be used as input parameters, and the weight coefficients should be dynamically adjusted according to peak business periods. For example, the throughput weight α is increased during peak periods, while the resource utilization weight β is increased during off-peak periods. The gradient descent algorithm uses parameters such as connection pool size and number of threads as independent variables during the solution process, calculates the gradient direction through backpropagation, and enforces the satisfaction of constraints through a penalty function or feasibility projection. The selection process compares the differences between candidate strategies and the current baseline, and combines simulation verification to eliminate invalid solutions, ensuring that the final strategy has a significant optimization effect.

[0077] This embodiment constructs an objective function by acquiring real-time performance metrics and historical baselines, generates candidate strategies by combining dynamic weight adjustment and constraint optimization algorithms, and then filters out invalid solutions through a threshold screening mechanism. This achieves the technical effect of improving the scientificity and practicality of optimization strategies. Specifically, objective function modeling ensures that strategy generation is directly related to business needs, such as prioritizing order processing throughput during e-commerce promotions; constraints ensure that parameter adjustments do not exceed system safety boundaries, avoiding resource overload and crashes; and the threshold screening mechanism reduces configuration disturbances caused by invalid strategies. Ultimately, this results in an adoption success rate of over 40% for adaptive optimization strategies, an average performance improvement of 20% to 30% after strategy implementation, and a 70% reduction in the probability of mistakenly triggering high-risk configurations.

[0078] In one embodiment, the complexity of the SQL statement is calculated using the database SQL audit log, and an index adjustment strategy for the database system is selected using a pre-established index optimization model, including: Obtain a set of slow query statements from the database SQL audit logs, and then perform syntax tree parsing and feature extraction on the slow query statement set to obtain the first SQL complexity data; Slow queries can be SQL statements whose execution time exceeds a preset threshold, such as the duration defined by the `long_query_time` parameter in the system configuration. Typical examples include full table scans or complex query structures. These statements can be obtained through database log files or the collection modules of monitoring tools, such as MySQL's `slow_query_log` or the results captured by third-party APM tools. Syntax tree parsing can be a structured representation of SQL text converted into an abstract syntax tree, for example, through an ANTLR parser or the database's built-in parsing module. Its specific representation includes explicit representations of node hierarchy or operator precedence. First SQL complexity data can be a set of metrics that quantify the difficulty of statement execution, such as a comprehensive score of the number of JOIN operations, subquery nesting depth, or the frequency of aggregate function usage.

[0079] This process can be exemplified through three sub-steps: threshold filtering, log filtering, and statement clustering. First, SQL queries with abnormal execution times are filtered out based on a preset time threshold. Second, statement variations are removed using regular expressions or parameterized matching. Finally, the statements are categorized according to query patterns to form a representative set. This technique allows focus on high-frequency, inefficient queries, avoiding redundant analysis, and providing structured input for subsequent feature extraction.

[0080] We analyze the current state of indexes for the data tables involved in the slow query statement set, and use a cost model to calculate the potential benefits of missing indexes to obtain the first index missingness data. The cost model can be a mathematical calculation framework based on database statistics, such as the I / O cost formula for B+ tree indexes or the matching efficiency model for hash indexes. Index status analysis can be a process of traversing and verifying the combinations and types of indexed fields, obtainable through database system tables such as information_schema.statistics or metadata interfaces of third-party tools. First index missingness data can be a score that quantifies the impact of missing indexes on query performance, such as the percentage of saved I / O operations or the percentage reduction in CPU time.

[0081] This process can be exemplified through three sub-steps: index scanning, cost calculation, and benefit assessment. First, the existing index configuration is recorded; second, the execution plan with and without indexes is simulated, and the difference in resource consumption is calculated; finally, the difference is converted into a comparable benefit score. This technique quantifies the specific impact of missing indexes, avoids blindly creating indexes, and provides a basis for subsequent optimization in terms of benefits.

[0082] Based on the joint evaluation of the first SQL complexity data and the first index missingness data, the recommended index fields and types are determined by query optimizer simulation, resulting in the first index recommended data and the first index adjustment data. Query optimizer simulation can be a simulation method that reproduces the decision-making process of a database query optimizer, such as predicting the execution plan through heuristic rules or machine learning models. First index recommendation data can be specific index creation suggestions, such as field combinations, uniqueness constraints, or index type selection. First index tuning data can be suggested solutions for modifying or deleting indexes, such as adjusting the included fields of an existing index.

[0083] This process can be exemplified through three sub-steps: feature fusion, optimizer simulation, and scheme generation. First, the SQL complexity score and the index missing benefit score are weighted and integrated. Second, execution plan selection under different index configurations is simulated. Finally, specific suggestions are generated based on the overall priority. This technique combines statement features and index benefits to generate targeted optimization schemes while reducing the subjective influence of human experience.

[0084] An assessment of the impact of storage space and write performance on the recommended data and adjusted data of the first index is conducted. The recommended parameters are constrained and verified using a preset index optimization model, and the index adjustment strategy of the database system is selected.

[0085] The impact on storage space can be the storage capacity occupied by a newly added index, calculated, for example, by multiplying the field data volume by the storage efficiency of the index type. The impact on write performance can be the negative impact of index maintenance operations on transaction latency, which can be estimated through benchmarking or historical data statistics. The preset index optimization model can be a linear programming model or a rule engine, with constraints including upper limits on storage usage or lower limits on write throughput.

[0086] This process can be exemplified through three sub-steps: impact modeling, constraint verification, and strategy selection. First, the storage requirements and write performance degradation of the new index are calculated. Second, resource consumption under high concurrency scenarios is simulated. Finally, constraints are input into the model to select feasible solutions. This technique balances performance improvement and resource consumption, avoiding storage bloat or write bottlenecks caused by optimization.

[0087] This embodiment achieves significant improvements in the accuracy and practicality of index optimization by focusing on slow query sets to reduce redundant analysis, structuring statement complexity into computable metrics, making decisions based on actual execution costs rather than theoretical assumptions, and filtering based on storage and write constraints. Specifically, it accurately identifies optimization targets, eliminates the subjectivity of human experience, ensures verifiable benefits, and reduces implementation risks, making it particularly suitable for write-intensive or storage-constrained database environments.

[0088] In one embodiment, the impact of adaptive tuning strategies and index adjustment strategies on the throughput, response latency, and resource utilization of the database system is evaluated to determine the target high-performance tuning strategy and the target high-performance indexing strategy, including: Obtain baseline data on throughput and average response latency before implementing adaptive tuning and index adjustment strategies in the database monitoring system, and obtain first evaluation data by performing performance profiling on the baseline data through time series analysis. Among them, throughput and average response latency benchmark data are a set of raw indicators characterizing the performance status of the database system before strategy implementation. These can be obtained by extracting historical operational data through the API interfaces of database monitoring tools (such as Prometheus or Grafana). Performance profiling, as a structured description of system performance characteristics, can include the statistical distribution of historical indicators (such as mean throughput and standard deviation of response latency), periodic patterns (such as peak business periods), and abnormal event markers (such as sudden load spikes). In a specific embodiment, performance profiling can be achieved by grouping time series data through cluster analysis (such as the K-means algorithm) or by extracting key feature dimensions through principal component analysis (PCA), thereby generating a multidimensional feature description of system performance. The time series analysis process may employ Empirical Mode Decomposition (EMD) to decompose the raw data into intrinsic mode functions to identify hidden periodic patterns.

[0089] Based on the first evaluation data, database operation data after the implementation of adaptive tuning strategy and index adjustment strategy was collected, and statistical analysis was used to calculate the percentage change in throughput and the percentage reduction in response latency to obtain the second evaluation data. The percentage change in throughput is a relative indicator measuring the improvement in system processing capacity after the strategy is implemented. It can be calculated as (mean after implementation / baseline) / baseline × 100%. The percentage reduction in response latency reflects the improvement in latency, calculated as (mean after implementation / baseline) / baseline × 100%. Statistical analysis may employ comparative experimental designs (such as A / B testing) to eliminate external interference factors, for example, by controlling for variables such as network fluctuations or system upgrades through analysis of covariance (ANCOVA). In one specific embodiment, the data collection process continuously records core indicators such as throughput and latency after the strategy takes effect, and uses a sliding window technique to calculate a rolling mean to eliminate the impact of transient noise.

[0090] The changes in CPU and memory resource utilization are calculated based on the second evaluation data, and the third evaluation data is obtained through the resource efficiency model. Changes in CPU and memory resource utilization are indicators that quantify the effectiveness of resource allocation optimization. They can be obtained by comparing the differences in resource monitoring data before and after the strategy implementation. For example, if CPU utilization increases from 70% to 85%, the change is +15%. Resource efficiency models, as mathematical tools linking resource usage to business performance, can be equations established through regression analysis (e.g., throughput improvement rate = α × CPU utilization change + β × memory efficiency coefficient) or calculation formulas based on physical rules. In a specific embodiment, Support Vector Machines (SVMs) can be used to nonlinearly model the relationship between memory bandwidth utilization and latency, determining the weights of each parameter through training on historical data.

[0091] A performance benefit calculator was used to comprehensively calculate the second and third evaluation data. Based on the business weight, the throughput improvement and latency reduction were weighted to obtain the comprehensive strategy benefit data. The performance benefit calculator is a tool that integrates multi-dimensional indicators. Its weighted calculations may employ a weighted summation method (e.g., benefit value = 0.6 × throughput weight + 0.4 × latency weight) or the Analytic Hierarchy Process (AHP) to construct a judgment matrix. Business weights are dynamically adjusted based on Service Level Agreements (SLAs). For example, an e-commerce system can increase the latency weight to 0.7 during promotional periods. In one specific embodiment, the fuzzy comprehensive evaluation method is used to handle the nonlinear relationships between indicators, mapping throughput, latency, and resource utilization to a unified benefit value through a membership function.

[0092] If the overall benefit data of the strategy shows that the throughput is higher than the benchmark and the response latency is lower than the benchmark, then the current tuning and indexing strategy is determined as the target high-performance tuning strategy and the target high-performance indexing strategy.

[0093] The overall benefit data of the strategy serves as the basis for the final decision. Its judgment logic employs a dual-threshold mechanism: throughput must exceed a preset percentage of the benchmark value (e.g., 1.1 times), while latency must be lower than the corresponding percentage of the benchmark value (e.g., 0.9 times). This judgment process is achieved by comparing the overall benefit value with the preset thresholds. If the targets are not met, a strategy rollback or reselection of a candidate strategy is triggered. In one specific embodiment, the thresholds can be dynamically adjusted based on historical performance fluctuations; for example, the throughput threshold can be set as a multiple of the standard deviation of the benchmark value to adapt to changes in business load.

[0094] This embodiment acquires benchmark data and generates a performance profile including statistical distribution, periodic patterns, and anomaly markers. It combines statistical analysis and comparative experiments to design and quantify the effectiveness of strategy implementation. Regression analysis or machine learning models are used to establish a quantitative correlation between resource efficiency and business performance. Weighted calculation or multi-objective optimization algorithms are employed to achieve a comprehensive, business-oriented benefit assessment. Finally, a dual-threshold judgment mechanism ensures that the strategy simultaneously meets the requirements of performance improvement and rational resource utilization. This achieves the following technical effects: accurate comparison based on historical baselines avoids interference from natural business fluctuations, improving the accuracy of strategy effectiveness evaluation; the resource efficiency model reveals the causal relationship between resource allocation and performance, preventing system instability due to over-optimization; dynamic weight configuration strongly couples strategy selection with business objectives—for example, financial systems can prioritize latency stability while data warehouses focus on throughput; the dual-threshold judgment mechanism balances multi-dimensional indicators, preventing global performance degradation caused by single-dimensional optimization, such as excessive memory usage leading to a surge in garbage collection latency.

[0095] In one embodiment, the key performance indicator curves and resource usage distribution after the implementation of the target high-performance tuning strategy and the target high-performance indexing strategy are monitored in real time, and time series analysis is performed to obtain performance indicator time series data. The performance indicator time series data is divided into samples of a set length, and the peak load rate and performance degradation rate of the samples are predicted to obtain prediction results. Based on the prediction results, a continuous optimization scheme for database configuration and indexing strategies is formed, including: By using spectrum analysis, the key performance indicator curves and resource usage distribution after the implementation of the target high-performance tuning strategy and the target high-performance indexing strategy are decomposed, and the first load mode data is calculated based on the periodic characteristics. Spectrum analysis can be a time-series analysis method based on Fourier transform, converting the time-domain signal into a frequency-domain spectrum using Fast Fourier Transform. For example, this method can identify repetitive fluctuation patterns such as daily or weekly cycles. Periodic characteristics can be recurring regular fluctuation features in time-series data, such as load peaks caused by batch tasks. The first load pattern data can be a structured parameter set containing information such as the dominant frequency component, amplitude, and phase. This can be obtained by filtering the dominant periodic component using peak detection algorithms and calculating its statistical characteristics. The technical operation can be achieved through three sub-steps: data standardization, frequency domain decomposition, and pattern parameter extraction. This includes eliminating dimensional differences, identifying the period length corresponding to significant frequency components, and quantifying the amplitude proportion and duration of periodic components, thereby achieving the technical effect of accurately identifying periodic load patterns.

[0096] Real-time performance metrics are calculated for the data under the first load mode. The metric curve is segmented using a sliding window to obtain the first performance time-series data. The sliding window can be a method of rolling out data segments at fixed time intervals; for example, a window length of one hour can be used. The first performance time series data can be a set of local features containing statistics such as the mean, variance, and trend slope of the indicators within the window. This can be obtained through three sub-steps: window partitioning, feature aggregation, and sequence recombination. The technical operation can be achieved by setting a window length that matches the load cycle characteristics, calculating the statistical features within each window, and recombinating the feature vectors into a new sequence in chronological order, thereby achieving the technical effect of transforming the original data into a structured periodic feature sequence.

[0097] The sample is divided based on the first performance time series data, and key indicators are extracted from the divided sample segments to obtain the second performance time series data. Key indicator extraction can involve selecting features that significantly impact load forecasting, such as throughput volatility and peak-to-peak resource utilization difference. The second set of performance time-series data can be a streamlined dataset after feature selection and dimensionality compression, obtained through three sub-steps: sample splitting, feature selection, and dimensionality compression. Technical operations can be implemented by dividing the dataset into training, validation, and test sets; using analysis of variance or random forests to evaluate feature importance; and employing principal component analysis or standardization methods to reduce dimensionality, thereby achieving the technical effect of reducing redundant features and improving forecasting efficiency.

[0098] A long short-term memory network is trained on the second performance time series data. Load change and performance degradation features are extracted from historical data to obtain the first prediction parameters. The Long Short-Term Memory (LSTM) network can be a recurrent neural network architecture with memory units, typically including an input layer, an LSTM hidden layer, and a fully connected output layer. Load variation characteristics can be parameters that quantify the amplitude, frequency, and abrupt change trends of load fluctuations, such as the QPS growth rate. Performance degradation characteristics can be parameters that describe the deterioration trend of indicators, such as the percentage decrease in throughput. The first prediction parameter can be an intermediate value such as the peak load probability or performance degradation rate output by the model. Technical operations can be implemented by constructing a neural network architecture, converting time-series data into tensor inputs, optimizing weight parameters through backpropagation, and using attention mechanisms to strengthen key features, thereby achieving the technical effect of capturing the impact of long-term cyclical patterns and short-term abrupt changes.

[0099] The first prediction parameter is used to calculate the peak load rate and performance degradation rate, and the second prediction parameter is obtained by judging through a threshold comparator. The threshold comparator can be a logical module that compares the predicted value with a preset safety threshold. An example safety threshold could be a 10% delay exceedance rate. The second prediction parameter can be a risk-classified identifier or correction value, such as low-risk or medium-risk levels. Technical operations can be implemented through parameter standardization mapping, comparison with a tiered threshold system, and generation of risk levels using fuzzy logic or tiered thresholds, thereby achieving the technical effect of transforming the model output into an actionable risk signal.

[0100] If the peak load rate or performance degradation rate exceeds the preset safety threshold, the current performance status data is recorded, and a configuration adjustment suggestion is generated based on the predicted deviation magnitude to obtain continuous database optimization parameters. Based on the continuous database optimization parameters, a continuous optimization scheme for database configuration and indexing strategies is obtained.

[0101] The configuration adjustment suggestions can be quantified as a change in parameters, such as increasing the connection pool size by 20%. Database continuous optimization parameters can be a comprehensive set of instructions including configuration parameters and index rebuilding suggestions. Technical operations can be implemented by recording state snapshots, calculating the difference between predicted values ​​and thresholds, generating suggestions based on an adjustment rule base, and using Bayesian optimization to generate candidate solutions, thereby achieving the technical effect of transforming prediction deviations into preventative adjustment strategies.

[0102] This embodiment achieves significant improvements in the accuracy of periodic load prediction and a reduction in the probability of service interruptions through steps such as spectrum analysis to decompose periodic load patterns, sliding window capture of local features, feature filtering to improve data quality, LSTM network modeling of long-term dependencies, threshold comparison to generate risk indicators, and deviation quantification to generate adjustment suggestions. Specifically, it enhances the ability to recognize periodic patterns through the deep integration of spectrum analysis and LSTM, reduces false positives and false negatives through a multi-level threshold system, improves operational efficiency through automated suggestion generation, and ultimately achieves continuous optimization of database configuration and indexing strategies.

[0103] Furthermore, this embodiment of the invention also proposes a storage medium storing a database operation and maintenance decision program based on a large language model. When the database operation and maintenance decision program based on a large language model is executed by a processor, it implements the steps of the database operation and maintenance decision method based on a large language model as described above.

[0104] In addition, refer to Figure 3 This invention also proposes a database operation and maintenance decision-making system based on a large language model, the database operation and maintenance decision-making system based on a large language model includes: The feature extraction module 10 is used to collect real-time operating indicators and historical log data from the database, and extract multi-dimensional time-series features of the real-time operating indicators and historical log data. The risk assessment module 20 is used to determine whether there are potential performance bottlenecks or abnormal risks based on the multi-dimensional time series features and using a large language model, and to determine the correlation between the multi-dimensional time series features and database performance issues. The tuning generation module 30 is used to obtain the current system load change trend and resource request rate if there are potential performance bottlenecks or abnormal risks, obtain system stress level data based on the load change trend and resource request rate, input the system stress level data into the performance optimization model, and output the adaptive tuning strategy of the database system. The index selection module 40 is used to calculate the complexity of SQL statements through the database SQL audit logs and select the index adjustment strategy of the database system through a pre-established index optimization model. The strategy evaluation module 50 is used to evaluate the impact of the adaptive tuning strategy and the index adjustment strategy on the throughput, response latency and resource utilization of the database system, and to determine the target high-performance tuning strategy and the target high-performance index strategy. The prediction and optimization module 60 is used to monitor the key performance indicator curves and resource usage distribution after the implementation of the target high-performance tuning strategy and the target high-performance indexing strategy in real time, and to perform time series analysis to obtain performance indicator time series data. The performance indicator time series data is divided into samples of a set length, and the peak load rate and performance decay rate of the samples are predicted to obtain prediction results. Based on the prediction results, a continuous optimization scheme for database configuration and indexing strategy is formed.

[0105] Other embodiments or specific implementations of the database operation and maintenance decision system based on a large language model described in this invention can be referred to the above-described method embodiments, and will not be repeated here.

[0106] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0107] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In the unit claims listing several systems, these systems may be embodied by the same hardware item. The use of the terms "first," "second," and "third," etc., does not indicate any order and can be interpreted as names.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as a read-only memory image (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal user device (which may be a mobile phone, computer, server, air conditioner, or network user device, etc.) to execute the methods described in the various embodiments of the present invention.

[0109] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural modifications made based on the description and drawings of this invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this invention.

Claims

1. A database operation and maintenance decision method based on a large language model, characterized in that, The method comprises: Collecting real-time running indicators and historical log data of the database, extracting multi-dimensional time sequence characteristics of the real-time running indicators and the historical log data; Based on the multi-dimensional time sequence characteristics, using a large language model to determine whether there is a potential performance bottleneck or abnormal risk, and determining the relevance of the multi-dimensional time sequence characteristics and the database performance problem; If there is a potential performance bottleneck or abnormal risk, obtain the current system load mutation trend and resource request rate, obtain the system stress degree data according to the load mutation trend and the resource request rate, input the system stress degree data into a performance optimization model, and output the adaptive tuning strategy of the database system; Calculate the SQL statement complexity through the database SQL audit log, and select the index adjustment strategy of the database system through the pre-established index optimization model; Evaluate the influence of the adaptive tuning strategy and the index adjustment strategy on the throughput, response delay and resource utilization of the database system, and determine the target high-performance tuning strategy and the target high-performance index strategy; Real-time monitoring of the key performance indicator curve and resource usage distribution after implementation of the target high-performance tuning strategy and the target high-performance index strategy, and performing time series analysis to obtain performance indicator time series data, dividing the performance indicator time series data into samples of a set length, predicting the load peak rate and performance decay rate of the samples, obtaining a prediction result, and forming a continuous optimization scheme for database configuration and index strategy according to the prediction result.

2. The database operation and maintenance decision method based on a large language model according to claim 1, wherein, The collection of real-time running indicators and historical log data of the database, and the extraction of multi-dimensional time sequence characteristics of the real-time running indicators and the historical log data, comprises: Collecting real-time running indicators and historical log data of the database, obtaining SQL execution flow data and system resource counter data based on the real-time running indicators and the historical log data, calculating load balancing parameters based on the SQL execution flow data and the system resource counter data, and obtaining a first running indicator sequence; Performing fast Fourier transform on the first running indicator sequence to decompose the load periodicity, and if the cycle energy density is higher than a baseline fluctuation threshold, a second running indicator sequence is generated; Obtaining short-term fluctuations and long-term trend components by wavelet decomposition on the second running indicator sequence, extracting connection pool usage rate change and transaction state persistence feature curves from the components, and obtaining a third running indicator sequence; Using a recursive least squares method to fit the third running indicator sequence to obtain a resource usage rate change feature curve, filtering high-frequency noise and low-frequency trends of the resource usage rate change feature curve through a feature selection algorithm, and obtaining multi-dimensional time sequence characteristics of query frequency data and I / O throughput data.

3. The database operation and maintenance decision method based on a large language model according to claim 1, wherein, The large language model is used to determine whether there is a potential performance bottleneck or abnormal risk based on the multi-dimensional time sequence characteristics, and the relevance of the characteristics and the database performance problem is determined, comprising: Based on the multi-dimensional time sequence feature, real-time performance index flow is obtained from a database monitoring endpoint, natural language description conversion is performed on the real-time performance index flow by a large language model to obtain description text, semantic matching calculation is performed on the description text in a preset risk keyword library to obtain a matching confidence, and a first risk feature data is obtained by comparing the matching confidence with a preset confidence threshold; According to the first risk feature data, an abnormal point is extracted from the real-time performance index flow, a sliding window is used to calculate a change gradient, and if the change gradient is greater than a preset mutation threshold, a first performance jitter feature data is generated; A context association and root cause feature extraction are performed on the first performance jitter feature data by an attention mechanism model to obtain a second risk feature data; The second risk feature data is analyzed by using semantic correlation calculation to extract event association features, and if the matching degree of the event association features exceeds a preset matching degree threshold, it is determined that the real-time running index is associated with a performance disturbance caused by a specific application load or configuration change.

4. The database operation and maintenance decision method based on a large language model of claim 1, wherein, If there is a potential performance bottleneck or abnormal risk, the current system load mutation trend and resource request rate are obtained, the system stress degree data is obtained according to the load mutation trend and the resource request rate, the system stress degree data is input into a performance optimization model, and the adaptive tuning strategy of the database system is output, including: If there is a potential performance bottleneck or abnormal risk, the current system load mutation trend and resource request rate are obtained from a database monitoring system, the current system load mutation trend and resource request rate are located by a mutation detection algorithm, and system stress degree data is obtained; According to the system stress degree data and the current system available resource data, a multivariate linear regression is used for data fitting to obtain a first resource response parameter; The first resource response parameter and historical tuning strategy data are optimized by a pre-established performance optimization model to obtain a second resource response parameter; According to the second resource response parameter, a connection pool size adjustment threshold and a working thread number adjustment parameter are calculated, the adjustment threshold and a response delay parameter are used to construct a tuning strategy matrix to obtain an adaptive tuning strategy of the database system, wherein the adaptive tuning strategy includes determining the memory allocation, the concurrency control parameter and the response load change speed of the database system.

5. The database operation and maintenance decision method based on a large language model according to claim 4, characterized in that, After the adaptive tuning strategy of the database system is obtained according to the second resource response parameter, the connection pool size adjustment threshold and the working thread number adjustment parameter, and the adjustment threshold and the response delay parameter are used to construct the tuning strategy matrix, the method further includes: The current memory usage rate, CPU utilization rate and buffer hit rate of the database system are obtained, and a performance target function is constructed in combination with a preset business peak period and a historical performance baseline; The target response time and the target resource utilization rate are set as constraint items, the gradient descent algorithm is used to solve the performance target function under the constraint items to obtain a candidate tuning strategy set; The tuning strategies with an expected improvement amplitude exceeding a preset performance threshold in the candidate tuning strategy set are screened out to obtain an adaptive tuning strategy.

6. The database operation and maintenance decision method based on a large language model according to claim 1, wherein, The SQL statement complexity is calculated through the database SQL audit log, and an index adjustment strategy of the database system is selected through a pre-established index optimization model, including: A slow query statement set is obtained from a database SQL audit log, first SQL complexity data is obtained by performing syntax tree analysis and feature extraction on the slow query statement set; Index present situation analysis is performed on data tables involved in the slow query statement set, and first index missing degree data is obtained by calculating the potential benefits of missing indexes using a cost model; Joint evaluation is performed on the first SQL complexity data and the first index missing degree data, recommended index fields and types are determined through query optimizer simulation, and first index recommendation data and first index adjustment data are obtained; Storage space and write performance influence evaluation is performed on the first index recommendation data and the first index adjustment data, recommended parameters are verified by constraint through a pre-set index optimization model, and an index adjustment strategy of the database system is selected.

7. The database operation and maintenance decision method based on a large language model according to claim 1, wherein, The influence of the adaptive tuning strategy and the index adjustment strategy on the throughput, response delay and resource utilization of the database system is evaluated, and a target high-performance tuning strategy and a target high-performance index strategy are determined, including: Through time series analysis, first evaluation data is obtained by performing performance profiling on the benchmark data before the adaptive tuning strategy and the index adjustment strategy are implemented. According to the first evaluation data, database running data after the adaptive tuning strategy and the index adjustment strategy are implemented is collected, and second evaluation data is obtained by calculating the throughput change percentage and the response delay reduction percentage using statistical analysis. According to the second evaluation data, the change value of CPU and memory resource utilization is calculated, and third evaluation data is obtained by calculating the resource efficiency model. The second evaluation data and the third evaluation data are comprehensively calculated using a performance benefit calculator, and the throughput improvement and delay reduction are weighted according to the business weight to obtain strategy comprehensive benefit data. If the strategy comprehensive benefit data shows that the throughput is higher than the benchmark value and the response delay is lower than the benchmark value, the current tuning and index strategy is determined as the target high-performance tuning strategy and the target high-performance index strategy.

8. The database operation and maintenance decision method based on a large language model of claim 1, wherein, The key performance indicator curve and resource usage distribution after the target high-performance tuning strategy and the target high-performance index strategy are implemented are monitored in real time, and time series analysis is performed to obtain performance indicator time series data. The performance indicator time series data is segmented into samples of a set length, the load peak rate and performance decay rate of the samples are predicted, a prediction result is obtained, and a continuous optimization scheme of database configuration and index strategy is formed according to the prediction result, including: Through frequency spectrum analysis, the key performance indicator curve and resource usage distribution after the target high-performance tuning strategy and the target high-performance index strategy are implemented are decomposed, and first load mode data is obtained according to the periodic characteristics. Real-time performance index calculation is performed on the first load mode data, a sliding window is used to perform segmented processing on an index curve, and first performance time series data is obtained; Sample division is performed according to the first performance time series data, key indicators are extracted from the divided sample segments, and second performance time series data is obtained; Long short-term memory network training is performed on the second performance time series data, load variation and performance decay characteristics are extracted from historical data, and first prediction parameters are obtained; The first prediction parameters are used to calculate load peak value rates and performance decay rates, a threshold comparator is used for judgment, and second prediction parameters are obtained; If the load peak value rate or the performance decay rate exceeds a preset safety threshold, current performance state data is recorded, a configuration adjustment suggestion amount is generated according to a predicted deviation amplitude, database continuous optimization parameters are obtained, and a continuous optimization scheme of database configuration and index strategy is obtained according to the database continuous optimization parameters.

9. A database operation and maintenance decision device based on a large language model, characterized by, The device comprises a memory, a processor, and a large language model-based database operation and maintenance decision program stored on the memory and executable on the processor, and the large language model-based database operation and maintenance decision program is configured to implement the steps of the large language model-based database operation and maintenance decision method according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium stores a large language model-based database operation and maintenance decision program, and the large language model-based database operation and maintenance decision program implements the steps of the large language model-based database operation and maintenance decision method according to any one of claims 1 to 8 when executed by the processor.

Images