State detection method and system for database product, and electronic device

Abstract

Provided in the present disclosure are a state detection method and system for a database product, and an electronic device. The method comprises: acquiring at least one query operation responded by a database product within a historical detection time period; identifying at least one fluctuation query operation from among the at least one query operation, wherein the fluctuation query operation is a query operation with a response time exceeding a time threshold value among the at least one query operation; determining a state detection index of the database product on the basis of the at least one fluctuation query operation and the at least one query operation, wherein the state detection index is used for representing a stability state in which the database product is; and if the state detection index is greater than a state detection index threshold value, determining that the database product is in an abnormal stability state within the historical detection time period. The present disclosure solves the technical problem of the state detection efficiency of database products being low.

Description

[0001]This disclosure claims priority to Chinese patent application number 202410084770.2, filed with the China Patent Office on January 19, 2024, entitled "Database Product Status Detection Method, System, and Electronic Device," the entire contents of which are incorporated herein by reference. Technical Field: This disclosure relates to the field of data management technology, and more specifically, to a database product status detection method, system, and electronic device. Background: Currently, database products with a large number of customers face complex status stability issues. When an urgent status stability issue arises, the entire process, from problem discovery to work order reporting, troubleshooting by frontline R&D personnel, and ultimately resolution, is time-consuming, impacting user experience. Consequently, there exists the technical problem of low database product status detection efficiency. Currently, no effective solution has been proposed to address this issue. SUMMARY: Embodiments of the present disclosure provide a database product status detection method, system, and electronic device to at least address the technical problem of low database product status detection efficiency. According to one aspect of an embodiment of the present disclosure, a method for detecting the status of a database product is provided, applied to a cloud server on which the database product is deployed. The method may include: obtaining at least one query operation responded to by the database product within a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold; determining a status detection indicator of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to represent the stability state of the database product; and if the status detection indicator is greater than the status detection indicator threshold, determining that the database product was in an abnormal stability state within the historical detection period. According to another aspect of an embodiment of the present disclosure, a method for detecting the status of a database product is also provided, applied to a cloud server on which the database product is deployed.The method may include: obtaining at least one query operation responded to by a database product within a historical detection period by invoking a first interface, wherein the first interface includes a first parameter, the parameter value of the first parameter being the at least one query operation; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query whose response time exceeds a time threshold among the at least one query operation; determining a status detection indicator of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product; if the status detection indicator is greater than a status detection indicator threshold, determining that the database product is in an abnormal stability state within the historical detection period; and outputting a prompt indicating the abnormal stability state by invoking a second interface, wherein the second interface includes a second parameter, the parameter value of the second parameter being a prompt indicating the abnormal stability state. According to another aspect of an embodiment of the present disclosure, a status detection device for a database product is also provided. The device may include: an acquisition unit configured to acquire at least one query operation responded to by a database product within a historical detection period; a first identification unit configured to identify at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; a first determination unit configured to determine a status detection indicator of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product; and a second determination unit configured to determine that the database product was in an abnormal stability state within the historical detection period when the status detection indicator is greater than the status detection indicator threshold. According to another aspect of the embodiments of the present disclosure, a status detection device for a database product is also provided.The apparatus may include: a first calling unit, configured to call a first interface to obtain at least one query operation responded to by a database product within a historical detection period, wherein the first interface includes a first parameter, the parameter value of the first parameter being the at least one query operation; a second identifying unit, configured to identify at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query whose response time exceeds a time threshold among the at least one query operation; a third determining unit, configured to determine a status detection indicator of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to represent the stability state of the database product; a fourth determining unit, configured to determine that the database product is in an abnormal stability state within the historical detection period when the status detection indicator is greater than a status detection indicator threshold; and a second calling unit, configured to call a second interface to output a prompt message indicating an abnormal stability state, wherein the second interface includes a second parameter, the parameter value of the second parameter being a prompt message indicating an abnormal stability state. According to another aspect of the embodiments of the present disclosure, a status detection system for a database product is also provided. The status detection system may include: a client for uploading a status detection instruction for a database product; a cloud server for, in response to the status detection instruction, obtaining at least one query operation responded to by the database product within a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein a fluctuating query operation is a query whose response time exceeds a time threshold among the at least one query operation; determining a status detection indicator for the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product; if the status detection indicator is greater than the status detection indicator threshold, determining that the database product is in an abnormal stability state within the historical detection period; and returning a prompt indicating the abnormal stability state to the client. According to another embodiment of the present disclosure, an electronic device is provided, comprising a memory and a processor, the memory being configured to store computer-executable instructions, and the processor being configured to execute the computer-executable instructions, wherein the computer-executable instructions are executed by the processor to perform the steps of a method for detecting the status of a database product. According to another embodiment of the present disclosure, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program processor executes, the computer-readable storage medium controls the device containing the computer-readable storage medium to execute the steps of the method for detecting the status of a database product. According to another aspect of an embodiment of the present disclosure, a computer program product is further provided, including computer instructions, which, when executed by a processor, implement the steps of the database product status detection method of an embodiment of the present disclosure.In an embodiment of the present disclosure, at least one query operation responded to by a database product within a historical detection period is obtained; among the at least one query operation, at least one fluctuating query operation is identified, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; based on the at least one fluctuating query operation and the at least one query operation, a state detection indicator of the database product is determined, wherein the state detection indicator is used to characterize the stability state of the database product; and if the state detection indicator is greater than the state detection indicator threshold, it is determined that the database product is in an abnormal stability state within the historical detection period. That is, in the embodiments of the present disclosure, the status detection index is determined based on at least one fluctuating query operation and at least one query operation within the historical detection period. Therefore, the status detection index can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index of the database product is compared with the status detection index threshold. If the status detection index is greater than the status detection index threshold, the database product is determined to be in an abnormally stable state. In other words, the embodiments of the present disclosure eliminate the need for manual troubleshooting and use the status detection index threshold as a data reference. When the status detection index is greater than the status detection index threshold, the database product can be automatically determined to be in an abnormally stable state. This significantly reduces troubleshooting time when database product problems arise, provides a foundation for automated operation and maintenance of the database product, improves user experience, and solves the technical problem of low database product status detection efficiency. It should be noted that the general description above and the detailed description that follows are merely examples and explanations of the present disclosure and do not constitute limitations of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation on the present disclosure.In the accompanying drawings: Figure 1 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a database product status detection method according to an embodiment of the present disclosure; Figure 2 is a structural block diagram of a computing environment according to an embodiment of the present disclosure; Figure 3 is a structural block diagram of a service grid according to an embodiment of the present disclosure; Figure 4 is a flow chart of a database product detection method according to an embodiment of the present disclosure; Figure 5 is a database product status detection method according to an embodiment of the present disclosure; Figure 6 is a schematic diagram of a database product status detection system according to an embodiment of the present disclosure; Figure 7 is a schematic diagram of a volatility upper limit multiplier changing with the median of the historical response time of a SQL pattern according to an embodiment of the present disclosure; Figure 8 is a schematic diagram of another volatility upper limit multiplier changing with the median of the historical response time of a SQL pattern according to an embodiment of the present disclosure; Figure 9 is a flow chart of a root cause troubleshooting method based on time series correlation according to an embodiment of the present disclosure; Figure 10 is a schematic diagram of a database product status detection device according to an embodiment of the present disclosure; Figure 11 is a schematic diagram of a database product status detection device according to an embodiment of the present disclosure; Figure 12 is a structural block diagram of a computer terminal according to an embodiment of the present disclosure. DETAILED DESCRIPTION To help those skilled in the art better understand the present disclosure, the following will provide a clear and complete description of the technical solutions in the embodiments of the present disclosure, in conjunction with the accompanying drawings. It should be noted that the described embodiments represent only a portion of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort should fall within the scope of protection of the present disclosure. It should be noted that the terms "first," "second," and so on, in the specification and claims of the present disclosure, and in the accompanying drawings, are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that such terms are interchangeable where appropriate, such that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to the steps or units expressly listed, but may include other steps or units not expressly listed or inherent to such process, method, product, or apparatus.First, some nouns or terms used in describing the embodiments of the present disclosure are subject to the following interpretations: Query response time refers to the time between a query operation being sent to a database system and the database system returning the corresponding query result; Query language pattern refers to a pattern or wildcard used in a query statement, used to match part or all of the text data. Queries with the same query language pattern refer to query statements with the same structure and syntax. For example, the result is obtained by replacing specific parameters in the query language with wildcards, thereby templating the query language; Status detection indicator refers to an indicator used to indicate whether the database product is in a stable state; Median response time refers to the response time corresponding to the median of multiple response time values; Target anomaly indicator refers to a query indicator that causes stability anomalies in the database product. Example 1 According to an embodiment of the present disclosure, a method for detecting the status of a database product is provided. It should be noted that the steps shown in the flowcharts of the accompanying figures can be executed in a computer system, such as a set of computer-executable instructions. Although the flowcharts show a logical order, in some cases, the steps shown or described may be executed in a different order than shown. The method embodiment provided in the first embodiment of the present disclosure can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 is a hardware block diagram of a computer terminal (or mobile device) for implementing a database product status detection method according to an embodiment of the present disclosure. As shown in Figure 1 , the computer terminal 10 (or mobile device) may include one or more processors 102 (illustrated as 102a, 102b, 102n in the figure) (the processor 102 may include, but is not limited to, a microprocessor (MCU) or a processing device such as a programmable logic device (FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, the device may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in Figure 1 is merely illustrative and does not limit the structure of the electronic device described above. For example, the computer terminal 10 may include more or fewer components than those shown in FIG. 1 , or may have a configuration different from that shown in FIG. 1 .It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present disclosure, the data processing circuitry functions as a processor control (e.g., selecting a variable resistor terminal path connected to an interface). The memory 104 may be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the database product status detection method in the embodiments of the present disclosure. The processor 102 executes the software programs and modules stored in the memory 104 to execute various functional applications and data processing, thereby implementing the aforementioned database product status detection method. The memory 104 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memories remotely located relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of such networks may include a wireless network provided by the communications provider of the computer terminal 10. In one instance, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one instance, the transmission device 106 may be a radio frequency (RF) module for wireless communication with the Internet. The display may be, for example, a touchscreen liquid crystal display (LCD), which enables a user to interact with the user interface of the computer terminal 10 (or mobile device).The hardware structure block diagram shown in FIG1 can serve not only as an exemplary block diagram of the aforementioned computer terminal 10 (or mobile device), but also as an exemplary block diagram of the aforementioned server. In an alternative embodiment, FIG2 shows a block diagram of an embodiment using the computer terminal 10 (or mobile device) shown in FIG1 as a computing node in a computing environment 201. FIG2 shows a structural block diagram of a computing environment. As shown in FIG2 , computing environment 201 includes multiple computing nodes (e.g., servers) (illustrated as 210-1, 210-2, ...) running on a distributed network. Each computing node includes local processing and memory resources. End users 202 can remotely run applications or store data in computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 in computing environment 201, representing services "A," "D," "E," and "H," respectively. End user 202 may provision and access services through a web browser or other software application on a client, and in some embodiments, the end user's 202 provisioning and / or requests may be provided to an ingress gateway 230 . oIngress gateway 230 may include a corresponding agent to handle the provisioning and / or requests for services (one or more services provided in computing environment 201). Services are provided or deployed based on various virtualization technologies supported by computing environment 201. In some embodiments, services may be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar approaches. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While VMs virtualize machines, container-based virtualization can launch containers to virtualize an entire operating system (OS), allowing multiple workloads to run on a single OS instance. In one embodiment based on container virtualization, several service containers may be assembled into a pod (e.g., a Kubernetes pod). For example, as shown in Figure 2, service 220-2 can be configured with one or more Pods 240-1, 240-2, ..., 240-N (collectively, Pods). A Pod can include a proxy 245 and one or more containers 242-1, 242-2, ..., 242-M (collectively, containers). One or more containers in a Pod process requests related to one or more corresponding functions of the service. Proxy 245 typically controls network functions related to the service, such as routing and load balancing. Other services can also be configured with Pods similar to Pods. During operation, executing a user request from end user 202 may require invoking one or more services in computing environment 201, and executing one or more functions of one service may require invoking one or more functions of another service. As shown in Figure 2, service "A" 220-1 receives a user request from end user 202 from ingress gateway 230. Service "A" 220-1 may call service "D" 220-2, which in turn may request service "E" 220-3 to perform one or more functions. The computing environment described above may be a cloud computing environment, where resource allocation is managed by the cloud service provider, allowing for the development of functions without having to worry about implementing, adjusting, or scaling servers. This computing environment allows developers to execute code in response to events without building or maintaining complex infrastructure. Services can be partitioned to perform a set of functions that can scale independently and automatically, rather than scaling a single hardware device to handle potential load.In another alternative embodiment, FIG3 shows a block diagram of an embodiment using the computer terminal 10 (or mobile device) shown in FIG1 as a service grid. FIG3 shows a structural block diagram of a service grid. As shown in FIG3 , service grid 300 is primarily used to facilitate secure and reliable communication between multiple microservices. Microservices refer to applications being decomposed into multiple smaller services or instances, distributed and running on different clusters / machines. As shown in FIG3 , microservices may include application service instance A and application service instance B, which form the functional application layer of service grid 300. In one embodiment, application service instance A runs as a container / process 308 on a machine / workload container group 314 (Pod), and application service instance B runs as a container / process 310 on a machine / workload container group 316 (Pod). In one embodiment, application service instance A may obtain at least one query operation responded to by a database product within a historical detection period and identify at least one fluctuation query operation within the at least one query operation. Application service instance B may determine a status detection indicator for the database product based on the at least one fluctuation query operation and the at least one query operation. As shown in Figure 3, application service instance A and grid agent 303 coexist in machine workload container group 614, while application service instance B and grid agent 305 coexist in machine workload container 314. Grid agents 303 and 305 form the data plane layer of service grid 300. Grid agents 303 and 305 run as container / process 304 and container / process 306, respectively, and can receive requests 312 for performing product query services. Bidirectional communication is possible between grid agent 303 and application service instance A, and between grid agent 305 and application service instance B. In addition, grid proxy 303 and grid proxy 305 can communicate bidirectionally. In one embodiment, traffic from application service instance A is routed to the appropriate destination via grid proxy 303, and network traffic from application service instance B is routed to the appropriate destination via grid proxy 305.It should be noted that the network traffic mentioned herein includes, but is not limited to, Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST), the high-performance, general-purpose open source framework (Google Remote Procedure Call (gRPC)), the open source in-memory data structure storage system (Redis), and the like. In one embodiment, the functionality of the extended data plane layer can be implemented by writing a custom filter for the proxy (Envoy) in the service grid 300. The service grid proxy configuration can be used to enable the service grid to correctly proxy service traffic and achieve service interoperability and service governance. Grid proxy 303 and grid proxy 305 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability. As shown in FIG3 , service grid 300 also includes a control plane layer. The control plane layer can be a set of services running in a dedicated namespace, hosted by a managed control plane component 301 within a machine / workload container group (machine / pod) 302. As shown in FIG3 , managed control plane component 301 communicates bidirectionally with grid proxy 303 and grid proxy 305. Managed control plane component 301 is configured to perform certain control and management functions. For example, managed control plane component 301 receives telemetry data transmitted by grid agent 303 and grid agent 305 and can further aggregate this telemetry data. For these services, managed control plane component 301 can also provide a user-oriented application programming interface (API) to facilitate manipulation of network behavior and provide configuration data to grid agent 303 and grid agent 305.In the above-described operating environment, the present disclosure provides a database product detection method, as shown in FIG4 , which is applied to a cloud server on which a database product is deployed. FIG4 is a flow chart of a database product detection method according to an embodiment of the present disclosure. As shown in FIG4 , the method may include the following steps: Step S401: Obtain at least one query operation responded to by the database product within a historical detection time period. In the technical solution provided in step S401 of the present disclosure, the database product includes query objects corresponding to multiple query operations. For example, the database product may be a database system or a database cluster, without specific limitation. The at least one query operation may be a total query of the database product within the historical detection time period. The query operation may be an operation that retrieves and obtains data from the database product using a query statement. The at least one query operation may be executed using Structured Query Language (SQL). The historical detection time period indicates a period of time in the past. The duration of the historical detection time period may be pre-set. For example, the historical detection time period may be the past minute, the past hour, etc., without specific limitation. In this embodiment, historical query records of the database product can be used to obtain at least one query operation that the database product responded to within a historical detection period. Each query operation corresponds to a query response time, which indicates the time elapsed between the query operation being sent to the database product and the database product returning the corresponding query result. For example, the query operations responded to by the database product and the corresponding query response times can be obtained by querying the database product's logs or using a detection tool. Step S402 identifies at least one fluctuating query operation within the at least one query operation. In the technical solution provided in step S402 of the present disclosure, as described in step S401, at least one query operation corresponds to a query response time. Based on this, after obtaining the at least one query operation that the database product responded to within the historical detection period, the at least one fluctuating query operation can be identified based on the query response time corresponding to the at least one query operation. The fluctuation query operation is a query operation in which the response time exceeds the time threshold in at least one query operation. The response time may also be referred to as query response time, query execution time, etc., which is not specifically limited here.The time threshold can be determined based on historical query response times of historical query operations that match the query pattern of the query operation. The query pattern indicates the pattern corresponding to the query language of the query operation, for example, a Structured Query Language pattern (SQL pattern). The query type of the query operation is the same as that of the historical query operation, including parameters of the same SQL pattern T, which can be replaced by wildcards. In this embodiment, the query response time corresponding to at least one query operation is compared with the time threshold. In response to the query response time of a query operation in at least one query operation exceeding the time threshold, the query operation is determined to be a fluctuating query operation. According to this method, at least one fluctuating query operation can be identified in the at least one query operation. Optionally, for each query operation within a historical detection period, the SQL pattern corresponding to the query operation can be determined. Multiple historical response times corresponding to query operations with the same SQL pattern during a period prior to the historical detection period can then be determined. A target response time can be determined based on the multiple historical response times. The target response time can be any one of the average response time, median response time, and maximum response time of the multiple historical response times, without specific limitation. After determining the target response time, the target response time can be multiplied by a fluctuation upper limit multiplier to obtain a time threshold. After determining the time threshold, the query response time of the query operation can be compared with the time threshold. If the query response time of the query operation is greater than the time threshold, the query operation is determined to be a fluctuating query operation. The fluctuation upper limit multiplier can be preset, for example, 2, without specific limitation. For example, assuming a fluctuation upper limit multiplier of 2, if the query response time of a query operation exceeds twice the median of the historical response times of queries with the same SQL pattern as the query operation during the period before the historical detection period, the query operation is determined to be a fluctuation query operation. Step S403: Determine the status detection indicator of the database product based on at least one fluctuation query operation and at least one query operation.In the technical solution provided in step S403 of the present disclosure, after determining at least one fluctuating query operation, a database product status detection indicator can be determined based on the at least one fluctuating query operation and the at least one query operation. The status detection indicator is used to characterize the stability state of the database product. For example, the status detection indicator can be a response time volatility indicator, which can be used to represent the query response time volatility. The query response time volatility can be the ratio of the number of fluctuating queries to the total number of queries in the database product during a historical detection period. In this embodiment, the at least one fluctuating query operation indicates a query operation whose query response time exceeded a time threshold among at least one query operation responded to by the database product during the historical detection period. The at least one query operation indicates the total number of query operations responded to by the database product during the historical detection period. Based on this, the database product status detection indicator can be determined based on the ratio of the number of at least one fluctuating query operation to the number of at least one query operation during the historical detection period. That is, the query response time volatility of the database product can be determined, and the stability state of the database product during the historical detection period can be determined based on the volatility. In step S404, if the status detection indicator is greater than the status detection indicator threshold, the database product is determined to be in an abnormally stable state during the historical detection period. In the technical solution provided in step S404 of the present disclosure, after determining the status detection indicator of the database product, the status detection indicator can be compared with the status detection indicator threshold to determine the stability of the database product during the historical period. The status detection indicator threshold is a threshold for determining whether the database product is in an abnormally stable state. The specific value of the status detection indicator threshold can be preset and is not specifically limited herein. In this embodiment, if the status detection indicator is greater than the status detection indicator threshold, the database product is determined to be in an abnormally stable state during the historical detection period. For example, assuming the status detection indicator threshold is 20%, if the ratio of the number of fluctuation query operations to the total number of queries during the historical detection period is greater than 20%, it indicates that the database product is in an abnormally stable state. As described in the aforementioned step S403, the database product's status detection indicator can be the query response time fluctuation rate of the database product during a historical detection period. That is, the ratio of the number of at least one fluctuating query operation to the number of at least one query operation during the historical detection period. Based on this, the database product's status detection indicator can be compared with a status detection indicator threshold of 20%. If the status detection indicator is greater than 20%, it indicates that the database product's status detection indicator is greater than the status detection indicator threshold, and it can be determined that the database product is in an abnormally stable state.Conversely, if the status monitoring indicator is less than 20%, it indicates that the database product's status detection indicator is not greater than the status detection indicator threshold, meaning that the database product is in a normal stability state. Based on steps S401 to S404 of the above embodiment, the status detection indicator is determined based on at least one fluctuation query operation and at least one query operation within the historical detection period. Therefore, the status detection indicator can accurately represent the proportion of fluctuation query operations within the historical detection period. Based on this, the database product's status detection indicator is compared with the status detection indicator threshold. If the status detection indicator is greater than the status detection indicator threshold, it can be determined that the database product is in an abnormally stable state. In other words, without manual troubleshooting, using the status detection indicator threshold as a data reference, when the status detection indicator is greater than the status detection indicator threshold, it can be automatically determined that the database product is in an abnormally stable state. This significantly reduces troubleshooting time when database product issues arise, provides a foundation for automated operation and maintenance of the database product, improves user experience, and addresses the technical issue of low database product status detection efficiency. The above method of this embodiment is further described below. As an optional implementation, step S403 determines a database product status detection indicator based on at least one waveform query operation and at least one query operation, including: counting the number of fluctuation queries executed during the fluctuation query operation and the total number of query operations executed; determining the ratio of the number of fluctuation queries to the total number of queries executed; and using the ratio as the database product status detection indicator. In this embodiment, the at least one fluctuation query operation indicates the number of query operations responded to by the database product within a historical detection period whose query response time exceeded a time threshold, and the at least one query operation indicates the total number of query operations responded to by the database product within the historical detection period. Based on this, the number of fluctuation queries executed during the fluctuation query operation and the total number of query operations executed by the database product within the historical detection period can be counted. Subsequently, the ratio of the number of fluctuation queries executed during the historical detection period to the total number of queries executed can be determined, and this ratio can be used as the database product status detection indicator. In other words, the status detection indicator is the query response time fluctuation rate within the historical detection period.For example, assuming the historical detection period is the past minute, the database product responded to 10 fluctuation queries within the past minute, and the total number of query operations responded to was 50. Since the ratio of the number of fluctuation queries to the total number of queries is 20%, that is, the number of fluctuation queries in the database product accounted for 20% of the total number of queries in the past minute. Based on this, 20% can be determined as the database product status detection indicator, that is, the query response time fluctuation rate in the past minute was 20%. As an optional implementation, the database product status detection method further includes: if the ratio is greater than a preset ratio threshold, determining that the status detection indicator is greater than the status detection indicator threshold, where the status detection indicator threshold includes a ratio threshold. In this embodiment, the ratio threshold is a data parameter that measures whether the database product status detection indicator is greater than the status detection indicator threshold. Based on this, after determining the ratio of the number of fluctuation queries to the total number of queries in the database product during the historical detection period, the ratio can be compared with the preset ratio threshold. If the ratio is greater than the ratio threshold, it can be determined that the status detection indicator is greater than the status detection indicator threshold. Optionally, if the proportion of the number of fluctuating queries to the total number of queries in the database product during the historical detection period is no greater than a proportion threshold, then the status detection index can be determined to be no greater than the status detection index threshold. As an optional implementation, the database product status detection method further includes: determining a query pattern matched by at least one query operation; and determining a time threshold based on the query pattern. In this embodiment, the query operation can be executed using a query language, and query languages ​​correspond to different query patterns. Therefore, after determining the at least one query operation responded to by the database product during the historical period, the query pattern matched by the query operation can be determined based on the query language corresponding to the at least one query operation. Different query patterns correspond to different time thresholds. Therefore, after determining the query pattern corresponding to the query operation, the corresponding time threshold can be determined based on the query pattern. The time threshold corresponding to a query pattern can be determined based on the median query response time of query operations of the query pattern within a period of time prior to the historical detection period. For example, the query language can be SQL, and the query pattern corresponding to the SQL language can be an SQL pattern. The SQL pattern indicates the result obtained after the SQL language is templated. The SQL pattern corresponding to each query operation during the historical detection period can be determined based on the SQL language corresponding to the query operation, and then the time threshold corresponding to the corresponding query operation can be obtained based on the SQL pattern.As an optional implementation, determining a time threshold based on a query pattern includes: obtaining at least one historical query operation matching the query pattern within a preset period prior to a historical detection period on a database product; determining a historical response time for the historical query operation; and determining the time threshold based on the historical response time. In this embodiment, the data source range and accuracy of the time threshold statistics may vary based on different application scenarios. For example, the preset period may be one week, two weeks, or one month prior to the historical detection period, without specific limitation. The at least one historical query operation matching the query pattern may be a query operation corresponding to a query pattern similar to or identical to the query pattern within the preset period. The historical response time may be the query response time of the at least one historical query matching the query pattern within the preset period. For example, assuming the preset period is one week prior to the historical detection period and the query pattern is an SQL pattern, the query response times of multiple historical queries corresponding to SQL patterns identical to or similar to the SQL pattern within the past week may be determined based on the SQL pattern, and the determined query response times may be used as the historical response times corresponding to the query operation corresponding to the SQL pattern. After determining the historical response times of historical queries matching the SQL pattern, a time threshold can be determined based on the historical response times. As an optional implementation, determining the time threshold based on the historical response times includes: determining a target response time based on multiple historical response times corresponding to multiple historical query operations, where the target response time describes the overall statistical results of the multiple historical response times; and determining the time threshold based on the target response time. In this embodiment, after determining the historical response times of multiple historical query operations matching the query pattern, a target response time can be further determined based on the multiple historical response times corresponding to the multiple historical query operations. The target response time can be any one of the median response time of the multiple historical response times, the average response time of the multiple historical response times, the response time corresponding to a percentile of the multiple historical response times (e.g., the P80 of the multiple historical response times), or the maximum response time of the multiple historical response times. Determination of the target response time is not specifically limited herein.For example, the median response time can be determined based on the median of multiple historical response times; the average response time can be determined based on the average of multiple historical response times; the P80 of multiple historical response times can be determined based on the 80th percentile of the multiple historical response times, that is, based on the 80th percentile of the multiple historical response times; and the maximum response time can be determined based on the maximum value of the multiple historical response times. The target response time can also be one of the aforementioned response times or a response time other than the aforementioned response times, without specific limitation herein. As an optional implementation, determining a time threshold based on the target response time includes: determining an adjustment parameter based on the target response time, where the adjustment parameter represents a multiple by which the target response time is adjusted; adjusting the target response time according to the adjustment parameter; and determining the adjusted target response time as the time threshold. In this embodiment, the adjustment parameter represents a multiple by which the target response time is adjusted, for example, an upper limit multiple for fluctuation queries. The query operations responded to by the database product may be short or long queries. Short queries are typically used to indicate quick, simple database query operations, resulting in shorter response times. Long queries are typically used to indicate complex, time-consuming database query operations, resulting in longer response times. To avoid misjudgments of fluctuations, a larger fluctuation range can be set for short queries with shorter response times, i.e., a larger adjustment parameter can be set for these queries. A shorter fluctuation range can be set for long queries with longer response times, i.e., a smaller adjustment parameter can be set for these queries. The adjustment parameter can be determined based on the target response time of the query operation. For example, the target response time can be the median of historical response times for query operations that match the query pattern of the query operation. For example, assuming the upper limit fluctuation multiplier is y times, the target response time can be adjusted based on the upper limit fluctuation multiplier y. For example, the target response time can be multiplied by the upper limit fluctuation multiplier to obtain the adjusted target response time, which is then used as the time threshold. For example, assuming that the fluctuation upper limit multiplier is 2, then twice the target response time can be determined as the time threshold. For example, the adjustment parameter can be determined by a weighted function of the following function.y = e'(Same SQL_Pattern Historical Response Time Median / 200 - 2) + 2, where y can be used to represent an adjustment parameter, and Same SQL_Pattern Historical Response Time Median can be used to indicate the median historical response time of historical query operations in the period prior to the historical detection period, where the query pattern of the historical query operations in the period prior to the historical detection period is consistent with the query pattern of the query operations in the historical detection period. As an optional implementation, the database product status detection method further includes: determining a target abnormality indicator for the database product based on a status detection indicator corresponding to the abnormal stability state, where the target abnormality indicator is used to place the database product in the abnormal stability state. In this embodiment, as described above, when the status detection indicator is greater than a status detection indicator threshold, the database product is determined to be in the abnormal stability state. When the database product remains in the abnormal stability state, it can be determined that an abnormal indicator exists in the database product. The target abnormality indicator for the database product can be determined based on the status detection indicator corresponding to the abnormal stability state. For example, when a database product is in an abnormal stability state, a target abnormality indicator for the database product can be determined based on the state detection indicator in the abnormal stability state. The target abnormality indicator is the root cause of the abnormality in the database product. By determining the target abnormality indicator in the database product, the root cause of the abnormality can be identified. As an optional implementation, determining the target abnormality indicator for the database product based on the state detection indicator corresponding to the abnormal stability state includes: determining, based on the state detection indicator, an abnormal period during a historical detection period when the database product was in an abnormal stability state; determining, based on the abnormal period, a target abnormality indicator for the target abnormality indicator; determining the target abnormality indicator for the target abnormality indicator as the historical detection period, and returning to the following steps to obtain the state detection indicator for the target abnormality ... In this embodiment, the status detection indicator is used to indicate the stability state of the database product. The status detection indicator is obtained through fluctuation query operations and total query operations within a historical detection period. Based on this, when the database product is determined to be in an abnormal stability state within a historical period based on the status detection indicator, an abnormal period during which the database product experienced the abnormal stability state can be further determined. This abnormal period is used to indicate the time interval during which the database product's response time to the fluctuation query operation fluctuated abnormally.Optionally, after determining the abnormal period during which the database product exhibits an abnormal stability state, the start time of the fluctuation anomaly can be further determined. The start time of the fluctuation anomaly is the time when the database product responds to a fluctuation query operation. After determining the start time of the fluctuation anomaly, the time period can be extended forward by a period of time, for example, 30 minutes, based on the start time of the fluctuation anomaly. This is not specifically limited here. For ease of explanation, the extended forward time period can be referred to as the preceding time period. Based on this, the period consisting of the abnormal period and the preceding time period can be determined as the test period, i.e., the test time range. Optionally, after determining the test period, the test period can be determined as a historical detection period, and steps S401 to S403 are performed to obtain a state detection indicator for the test period. Optionally, after determining the state detection indicator for the test period, a target abnormality indicator for the database product can be determined based on the state detection indicator for the test period. As an optional implementation, determining a target abnormality indicator based on a state detection indicator during a test period includes: obtaining candidate abnormality indicators for the database product during the test period, wherein the candidate abnormality indicator is an indicator to be determined that causes the database product to be in an abnormally stable state; obtaining a correlation between the state detection indicator during the test period and the candidate abnormality indicator, wherein the correlation indicates the degree of correlation between the state detection indicator during the test period and the candidate abnormality indicator; and determining the candidate abnormality indicator as a target abnormality indicator in response to the correlation being greater than a correlation threshold, wherein the target abnormality indicator is used to cause the database product to be in an abnormally stable state. In this embodiment, the candidate abnormality indicator is an indicator to be determined that causes the database product to be in an abnormally stable state, wherein the candidate abnormality indicator may be a core indicator of the database product. Based on this, the candidate abnormality indicator for the database product during the test period may be obtained, and then the correlation between the state detection indicator during the test period and the candidate abnormality indicator may be obtained. The correlation may then be compared with a correlation threshold. In response to the correlation being greater than the correlation threshold, the candidate abnormality indicator may be determined as the target abnormality indicator. The correlation threshold may be preset, for example, the correlation threshold may be 0.8, which is further exemplified here.For example, a candidate anomaly indicator may be a cluster anomaly correlation indicator. The anomaly correlation indicator may include pattern-level indicators, scanned data volume, memory usage, transmitted data volume, Java Virtual Machine (JVM) memory usage, Java Virtual Machine Garbage Collection (JVM GC) time, network rewrite rate, transactions per second (TPS), and the like, without specific limitation. As an optional implementation, obtaining the correlation between the state detection indicator and the candidate anomaly indicator within a test period includes: obtaining a first eigenvector of the state detection indicator; obtaining a second eigenvector of the candidate anomaly indicator; and determining the correlation as the similarity between the first eigenvector and the second eigenvector. In this embodiment, the detection period corresponding to the state detection indicator and the detection period corresponding to the candidate anomaly indicator are the same; therefore, the number of data points corresponding to the two is also the same. Therefore, the two state detection indicators can be equated with two eigenvectors. For ease of explanation, the feature vector corresponding to the state detection indicator may be referred to as the first feature vector, and the feature vector corresponding to the candidate anomaly indicator may be referred to as the second feature vector. The similarity between the first feature vector and the second feature vector is then calculated, and this similarity is determined as the correlation between the state detection indicator and the candidate anomaly indicator within the test period. For example, the similarity between the first feature vector and the second feature vector may be determined using a cosine similarity algorithm. This is merely an example and does not limit the process of determining the similarity between the first feature vector and the second feature vector. As an optional embodiment, obtaining the first feature vector of the state detection indicator includes normalizing the state detection indicator to obtain the first feature vector. Obtaining the second feature vector of the candidate anomaly indicator includes normalizing the candidate anomaly indicator to obtain the second feature vector. In this embodiment, when obtaining the first feature vector of the state detection indicator, the state detection indicator may be normalized to obtain the first feature vector. Similarly, when obtaining the second feature vector of the candidate anomaly indicator, the second feature vector of the candidate anomaly indicator may be normalized to obtain the second feature vector. For example, the state detection index may be normalized using a z-score normalization method to obtain a first eigenvector, and the candidate anomaly index may be normalized to obtain a second detection index.It should be noted that the z-score normalization method is used to normalize the state detection indicator and the candidate anomaly indicator to a mean of 0, a variance of 1, and a mean of 0. This facilitates the subsequent calculation of the similarity between the first eigenvector of the state detection indicator and the second eigenvector of the candidate anomaly indicator. As an optional implementation, determining the target anomaly indicator's test period based on the anomaly period includes: determining a preceding period preceding the start time of the anomaly period; and determining the anomaly period and the preceding period as the test period. In this embodiment, as described above, the start time of the anomaly period is the time when the database product responds to the fluctuation query. The preceding period preceding the start time of the anomaly period can be a period extending forward from the start time of the anomaly period, for example, 30 minutes, without specific limitation. After obtaining the preceding period, since the anomaly period and the preceding period are adjacent time periods, the period consisting of the anomaly period and the preceding period can be determined as the test period. As an optional implementation, determining a target abnormality indicator for a database product based on a state detection indicator includes: inputting the state detection indicator into a machine learning model for prediction to obtain the target abnormality indicator. The machine learning model is trained based on state detection indicator samples and abnormality indicator samples of the database product. The state detection indicator samples are used to characterize the abnormal stability state of the database product, and the abnormality indicator samples are used to place the database product in the abnormal stability state corresponding to the state detection indicator samples. In this embodiment, when determining the target abnormality indicator for the database product based on the state detection indicator, the target abnormality indicator for the database product can be predicted using the machine learning model. For example, the machine learning model is pre-trained based on abnormality indicator samples of different database products in abnormal stability states. The abnormality indicator of the database product can be predicted based on the machine learning model. In the above steps, the status detection index is determined based on at least one fluctuating query operation and at least one query operation within the historical detection period. Therefore, the status detection index can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index of the database product is compared with the status detection index threshold. If the status detection index is greater than the status detection index threshold, it can be determined that the database product is in an abnormally stable state. In other words, without manual troubleshooting, the status detection index threshold is used as a data reference. When the status detection index is greater than the status detection index threshold, it can be automatically determined that the database product is in an abnormally stable state. This significantly reduces the troubleshooting time when database product problems arise, provides a foundation for automated operation and maintenance of database products, improves user experience, and solves the technical problem of low database product status detection efficiency. In the above operating environment, the present disclosure also provides a database product status detection method as shown in Figure 5, which is applied to a cloud server on which the database product is deployed. Figure 5 illustrates a database product status detection method according to an embodiment of the present disclosure. As shown in Figure 5, the method may include the following steps: Step 501: Obtain at least one query operation responded to by the database product during a historical detection period by invoking a first interface. In the technical solution provided in step S501 of the present disclosure, the first interface may be an interface for data exchange between a cloud server and a client. The server may obtain at least one query operation responded to by the database product during the historical detection period by invoking the first interface. The at least one query operation indicates all query operations responded to by the database product during the historical detection period. Step S502: Identify at least one fluctuation query operation among the at least one query operation. In the technical solution provided in step S502 of the present disclosure, at least one query operation corresponds to a query response time. Based on this, after obtaining at least one query operation responded to by the database product within a historical detection time period, at least one fluctuating query operation can be identified based on the query response time corresponding to the at least one query operation. The fluctuating query operation is a query operation in which the response time exceeds a time threshold among the at least one query operation. The response time may also be referred to as the query response time, the query execution time, etc., without specific limitation herein. The time threshold may be determined based on the historical query response time of historical query operations that match a query pattern of the query operation. The query pattern is used to indicate a pattern corresponding to the query language of the query operation, for example, a structured query language pattern (SQL pattern). oStep S503: Determine a status detection indicator for the database product based on at least one fluctuation query operation and at least one query operation. In the technical solution provided in step S503 of the present disclosure, after determining the at least one fluctuation query operation, the status detection indicator for the database product can be determined based on the at least one fluctuation query operation and the at least one query operation. The status detection indicator is used to characterize the stability state of the database product. For example, the status detection indicator can be the query response time fluctuation rate, where the query response time fluctuation rate can be the ratio of the number of fluctuation queries to the total number of queries in the database product during a historical detection period. Step S504: If the status detection indicator is greater than a status detection indicator threshold, it is determined that the database product was in an abnormal stability state during the historical detection period. In the technical solution provided in step S504 of the present disclosure, after determining the status detection indicator for the database product, the status detection indicator can be compared with the status detection indicator threshold to determine the stability state of the database product during the historical period. The status detection indicator threshold is a threshold for determining whether the database product is in an abnormal stability state. The specific value of the status detection indicator threshold can be preset and is not specifically limited here. In this embodiment, if the status detection indicator is greater than the status detection indicator threshold, the database product is determined to be in an abnormal stability state during the historical detection period. The specific implementation method can be found in the aforementioned step S404 and will not be further described here. In step S505, a prompt indicating the abnormal stability state is output by invoking the second interface. In the technical solution provided in step S505 of the present disclosure, the second interface may be an interface for data exchange between the cloud server and the client. After determining the stability state of the database product, if the database product is in an abnormal stability state, the cloud server may output a prompt indicating the abnormal stability state of the database product to the client via the second interface for display, allowing the user to troubleshoot the cause of the abnormality based on the content displayed on the client.In the technical solutions provided in steps S501 to S505 above, the stability of a database product is determined using a status detection indicator. Because the status detection indicator is determined based on at least one fluctuating query operation and at least one query operation within a historical detection period, the status detection indicator can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the database product's status detection indicator is compared with a status detection indicator threshold. If the status detection indicator is greater than the status detection indicator threshold, the database product is determined to be in an abnormally stable state. This eliminates the need for manual troubleshooting, using the status detection indicator threshold as a data reference. When the status detection indicator is greater than the status detection indicator threshold, the database product is automatically determined to be in an abnormally stable state. This significantly reduces troubleshooting time when database product issues arise, provides a foundation for automated operation and maintenance of database products, improves user experience, and addresses the technical issue of low database product status detection efficiency. Figure 6 is a schematic diagram of a database product status detection system according to an embodiment of the present disclosure. The database product status detection system 600 may include a client 601 and a cloud server 602. Client 601 is used to upload database product status detection instructions. In this embodiment, a status detection instruction is used to instruct the database product to detect at least one query operation responded to during a historical detection period. The status detection instruction can be input by a user into a client and uploaded to the cloud server via the client. Cloud server 602 is configured to, in response to the status detection instruction, obtain at least one query operation responded to by the database product during the historical detection period; identify at least one fluctuating query operation among the at least one query operation, wherein a fluctuating query operation is a query whose response time exceeds a time threshold; determine a status detection indicator for the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product; if the status detection indicator is greater than the status detection indicator threshold, determine that the database product is in an abnormal stability state during the historical detection period; and return a prompt indicating the abnormal stability state to the client. In this embodiment, after responding to the status detection instruction sent by the client, the cloud server can, based on the status detection instruction, obtain at least one query operation responded to by the database product during the historical detection period, wherein the at least one query operation is all query operations responded to by the database product during the historical detection period.After obtaining at least one query operation that the database product responded to within a historical detection period, at least one fluctuating query operation can be identified within the at least one query operation. A fluctuating query operation is a query whose response time exceeds a time threshold within the at least one query operation. Based on the at least one fluctuating query operation and the at least one query operation, a status detection indicator for the database product can be determined. If the status detection indicator exceeds the status detection indicator threshold, the database product is determined to be in an abnormal stability state within the historical detection period. After determining that the database product is in an abnormal stability state, a prompt indicating the abnormal stability state can be returned to the client, allowing the user to troubleshoot the cause of the database product anomaly based on the abnormal stability state. The following further illustrates the technical solutions of the disclosed embodiments with examples in conjunction with preferred implementations. Currently, stability issues for database products with a large number of customers are extremely complex. When an urgent stability issue arises, the entire process, from customer discovery to ticket submission, to frontline R&D personnel troubleshooting, and finally resolving the issue, is time-consuming, impacting user experience. Consequently, there exists a technical problem of low database product detection efficiency. However, the present disclosure provides a database product status detection method, which obtains at least one query operation responded to by the database product within a historical detection period; identifies at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; determines a database product status detection indicator based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to represent the stability status of the database product; and if the status detection indicator is greater than the status detection indicator threshold, determines that the database product is in an abnormal stability status within the historical detection period. That is, in the embodiments of the present disclosure, the status detection index is determined based on at least one fluctuation query operation and at least one query operation within a historical detection period. Therefore, the status detection index can accurately represent the proportion of fluctuation query operations within the historical detection period. Based on this, the status detection index of the database product is compared with the status detection index threshold. If the status detection index is greater than the status detection index threshold, it can be determined that the database product is in an abnormally stable state. In other words, manual troubleshooting is unnecessary. Using the status detection index threshold as a data reference, when the status detection index is greater than the status detection index threshold, it can be automatically determined that the database product is in an abnormally stable state. This significantly reduces troubleshooting time when database product problems occur, provides a foundation for automated operation and maintenance of the database product, improves user experience, and solves the technical problem of low status detection efficiency of the database product.Next, we will further discuss query response time fluctuation. In this embodiment, to automatically detect anomalies in a database product, an anomaly determination metric must be set. This metric should be neither too detailed, thereby only identifying localized issues, nor too general, thereby leading to numerous false positives. Because query response time fluctuation is a metric that users can directly perceive, it is used as an anomaly determination metric. The database product may be a database cluster, and this is not a specific limitation. The query response time fluctuation is calculated by combining the query response time of a query operation's query pattern (e.g., SQL pattern) over a period of time with the historical response time of that query pattern. When the execution time of a query operation exceeds y times the median of the historical response time of queries that match the SQL pattern of that query operation, the query operation is identified as a fluctuating query. The query response time fluctuation of a database product is defined as the ratio of the number of fluctuating queries to the total number of queries in the system over a period of time (the default is 1 minute). This is used to determine whether the system is currently in an abnormal state. By default, 20% is used as the threshold for determining whether a system is abnormal. That is, if 20% of queries within the past minute experience response time fluctuations, the algorithm automatically determines that the system is currently abnormal. Subsequent actions may include sending a phone alert or automatically reporting a problem. The method for determining the upper limit of the volatility multiplier is further described below. In this embodiment, the upper limit of the volatility multiplier can be set to a fixed value, such as 2. OHowever, a fixed value only addresses certain situations. For example, if the volatility cap multiplier is set to 2, a query whose response time exceeds twice the median historical response time of the query's SQL pattern will be identified as a fluctuating query. This applies to queries with long execution times, but database products often contain a large number of short queries. If a query with a historical median response time of only 10ms fluctuates to over 20ms due to some factors, this does not necessarily mean that the fluctuation is abnormal; otherwise, database products will experience a large number of false positives. Therefore, it is necessary to give shorter query times a wider range of normal fluctuations to avoid false positives, while setting a relatively reasonable volatility cap for larger queries. Large queries are processes that query and analyze large amounts of data, typically involving data from large databases or data warehouses, and require the use of complex query languages ​​and techniques to process and analyze large amounts of data. Alternatively, for large queries, if the time granularity is 1 minute, there's a high probability that the query will span two or more time granularities. This means that large queries may impact cluster stability for an entire period. If cluster stability issues occur during this period, they are likely related to the large query. Therefore, simply counting the query's metrics at the start or end of the query is inaccurate. Therefore, a method can be employed to count all the query's metrics at each time granularity it experiences. In other words, resource overhead for each time period throughout its lifecycle can be included to better describe cluster stress. Alternatively, a function can be used to determine the specific value of the volatility cap multiplier, as shown in the following formula: y = e'(Same SQL_Pattern Historical Response Time Median / 200 - 2) + 2, where y indicates the volatility cap multiplier. Figure 7 is a schematic diagram showing how the volatility cap multiplier changes with the SQL pattern historical response time median, according to an embodiment of the present disclosure. As shown in Figure 7, the horizontal axis indicates the median historical response time of SQL Pattern, and the vertical axis indicates the value of the volatility upper limit multiplier y calculated by the above function. When the median historical response time is around 10ms, the value is about 9 times, and when the median historical response time is around 1s, the value is about 2.05 times, and it will eventually converge to 2. OThis function allows for a higher fluctuation range for small queries. As query time increases, the fluctuation range becomes increasingly strict, ultimately converging to twice the median historical response time of the same SQL pattern. Figure 8 shows another schematic diagram of how the upper limit of the fluctuation rate varies with the median historical response time of the SQL pattern, according to an embodiment of the present disclosure. As shown in Figure 8, the horizontal axis represents the median historical response time of the SQL pattern, and the vertical axis represents the upper limit of response time fluctuation calculated using the above function. It can be seen that when the median historical response time of the SQL pattern is between 0 and 1000, the upper limit of the fluctuation increases rapidly, which is consistent with the expectation that short queries have a higher upper limit of fluctuation. When the median historical response time of the SQL pattern is above 1000, the upper limit of the fluctuation increases linearly with a slope close to 2. The following describes an algorithm for detecting abnormal response time fluctuations based on time series. To replace manual troubleshooting and simplify the troubleshooting process, this disclosure provides a root cause troubleshooting algorithm based on time series correlation to identify abnormal query metrics that contribute to database product stability anomalies. These metrics include query response time, the amount of random data shuffling performed on the dataset (data shuffling), scanned data volume, and memory usage, among other indicators, though these are not specifically limited. If persistent fluctuations in query response time occur in a database system, it can be determined that core metrics within the database product are abnormal. Abnormal query patterns are the primary cause of database product stability issues. In other words, these abnormal query patterns, also known as abnormal patterns, are often the primary cause of database product stability issues. oFigure 9 is a flowchart of a root cause troubleshooting method based on time series correlation according to an embodiment of the present disclosure. As shown in Figure 9, the method includes the following steps: Step S901: Calculate the query response time volatility index of the database product. In this embodiment, the volatility index of the query response times responded to by the database product within a historical detection period can be calculated to determine the start time of the abnormal fluctuation. This historical detection period can be the past minute, but this is not a limitation. Step S902: Determine a test period based on the query response time volatility index. In this embodiment, after determining the start time of the abnormal fluctuation in step S901, the start time of the abnormal fluctuation can be extended forward by a period of time, for example, 30 minutes, and this extended period is determined as the preceding period. This preceding period is combined with the time interval of the abnormal fluctuation to obtain the test period. Step S903: Determine the query response time volatility index data within the test period. In this embodiment, a data point can be recorded at a 1-minute granularity, meaning that a data point is recorded every 1-minute interval. Query response time volatility index data for the test period is then calculated based on the collected data points. Using a 1-minute granularity as a data point means that data is collected and recorded at 1-minute intervals during statistics and recording, and each data point represents the statistics and recording data within a 1-minute period. Step S904 collects all query metrics responded to by the database product during the test period. In this embodiment, all query metrics responded to by the database product during the test period are collected and aggregated using an aggregation method to obtain query metrics corresponding to all query patterns (SQL patterns). Query metrics may include core database product metrics such as scanned data volume, memory usage, and transferred data volume. The aggregation method may be a summation method. Optionally, this embodiment uses the summation method to aggregate query metrics corresponding to a query pattern, which may involve adding all query metrics for the same query pattern to obtain overall metric data for the query pattern. For example, query metrics such as the scanned data volume, memory usage, and transmitted data volume for the same SQL pattern are added together to obtain the total data volume of the SQL pattern. In step S905, the query response time volatility and query metrics within the test period are normalized. In this embodiment, the response time volatility and query metrics (e.g., scanned data volume and memory usage) within the test period can be normalized using z-score normalization, which is not specifically limited here. In step S906, feature amplification is performed on the normalized query response time volatility and query metrics.In this embodiment, a feature amplification algorithm can be used to amplify the query response time fluctuation and query index to more clearly observe data points that are far from the mean. Step S907: Calculate the similarity between the query response time fluctuation and the query index. In this embodiment, the similarity between the query response time fluctuation and the query index can be calculated. For example, the feature vectors corresponding to the query response time fluctuation and the query index can be determined, and then the similarity between the two can be determined using a cosine similarity algorithm. Step S908: Based on the similarity and a similarity threshold, determine abnormal query indicators with a high correlation with the query response time fluctuation. In this embodiment, after calculating the similarity, the similarity can be compared with the similarity threshold. If the similarity is greater than the similarity threshold, it indicates that the query indicator corresponding to the similarity is an abnormal query indicator. The similarity threshold can be pre-set, for example, 0.8, and is not specifically limited here. In this embodiment, by calculating abnormal query indicators with a high correlation with query response time fluctuation, abnormal query indicators with correlations above a threshold with query response time fluctuations can be automatically found, achieving the goal of automatically determining the root cause of database product stability anomalies. It should be noted that other core indicators of the database product, such as JVM memory usage and TPS (transaction times per second) can be aggregated and processed into a feature vector, and then similarity is calculated with the vector of query response time fluctuation, thereby automatically determining the root cause of the current system anomaly, significantly reducing troubleshooting time and improving the customer experience. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or deny. It should be noted that, for simplicity of description, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should understand that the present disclosure is not limited by the order of the actions described, as certain steps may be performed in a different order or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required for the present disclosure.Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the above embodiments can be implemented using software plus a necessary general-purpose hardware platform, or alternatively, hardware. Based on this understanding, the technical solution of the present disclosure, or the portion 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 ROM / RAM, a magnetic disk, or an optical disk) and includes instructions for enabling a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present disclosure. Example 2 According to an embodiment of the present disclosure, a database product status detection device for implementing the above-mentioned database product status detection method is also provided. Figure 10 is a schematic diagram of a database product status detection device according to an embodiment of the present disclosure. As shown in Figure 10, the database product status detection device 1000 may include an acquisition unit 1001, a first identification unit 1002, a first determination unit 1003, and a second determination unit 1004. oAn acquisition unit 1001 is configured to acquire at least one query operation responded to by a database product within a historical detection period. A first identification unit 1002 is configured to identify at least one fluctuating query operation among the at least one query operation, wherein a fluctuating query operation is a query operation whose response time exceeds a time threshold. A first determination unit 1003 is configured to determine a status detection indicator of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product. A second determination unit 1004 is configured to determine that the database product is in an abnormal stability state within the historical detection period when the status detection indicator is greater than the status detection indicator threshold. It should be noted that the acquisition unit 1001, first identification unit 1002, first determination unit 1003, and second determination unit 1004 described above correspond to steps S401 to S404 in Example 1. The examples and application scenarios implemented by these four units and the corresponding steps are the same, but are not limited to the contents disclosed in Example 1. It should be noted that the above-mentioned modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, 102n). The above-mentioned modules may also be executed as part of a device in the computer terminal 10 provided in the first embodiment. According to an embodiment of the present disclosure, a database product status detection device for implementing the above-mentioned database product status detection method is also provided. FIG11 is a schematic diagram of a database product status detection device according to an embodiment of the present disclosure. As shown in FIG11, the database product status detection device 1100 may include: a first calling unit 1101, a second identifying unit 1102, a third determining unit 1103, a fourth determining unit 1104, and a second calling unit 1105. oA first calling unit 1101 is configured to call a first interface to obtain at least one query operation responded to by a database product within a historical detection period, wherein the first interface includes a first parameter whose parameter value is the at least one query operation. A second identifying unit 1102 is configured to identify at least one fluctuating query operation among the at least one query operation, wherein a fluctuating query operation is a query whose response time exceeds a time threshold. A third determining unit 1103 is configured to determine a status detection indicator of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to represent the stability state of the database product. A fourth determining unit 1104 is configured to determine that the database product is in an abnormal stability state within the historical detection period when the status detection indicator is greater than the status detection indicator threshold. A second calling unit 1105 is configured to call a second interface to output a prompt message indicating an abnormal stability state, wherein the second interface includes a second parameter whose parameter value is a prompt message indicating an abnormal stability state. It should be noted that the first calling unit 1101, second identification unit 1102, third determination unit 1103, fourth determination unit 1104, and second calling unit 1105 described above correspond to steps S501 to S505 in Example 1. These five units and corresponding steps implement the same examples and application scenarios, but are not limited to the content disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1. It should be noted that the preferred implementation schemes, application scenarios, and implementation processes involved in the above embodiments of the present disclosure are the same as those provided in Example 1, but are not limited to the solutions provided in Example 1. Example 3 An embodiment of the present disclosure may provide an electronic device comprising a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may be replaced by a terminal device such as a mobile terminal. Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.In this embodiment, the computer terminal can execute program code for the following steps in the database product status detection method: obtaining at least one query operation responded to by the database product within a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; determining a database product status detection indicator based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product; and determining that the database product is in an abnormal stability state within the historical detection period if the status detection indicator is greater than the status detection indicator threshold. Optionally, FIG12 is a block diagram of a computer terminal according to an embodiment of the present disclosure. As shown in FIG12 , the computer terminal A may include one or more (only one is shown) processors 1202, a memory 1204, a storage controller, and a peripheral interface, wherein the peripheral interface is connected to a radio frequency module, an audio module, and a display. The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the database product status detection method and apparatus in the embodiments of the present disclosure. The processor executes the software programs and modules stored in the memory to perform various functional applications and data processing, thereby implementing the aforementioned database product status detection method. The memory can include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory can further include memory remotely located from the processor. Such remote memory can be connected to the computer terminal A via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The processor may call information and applications stored in the memory through a transmission device to perform the following steps: obtaining at least one query operation responded to by the database product within a historical detection period; identifying at least one fluctuation query operation among the at least one query operation, wherein the fluctuation query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; determining a status detection indicator of the database product based on the at least one fluctuation query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product; and determining that the database product is in an abnormal stability state within the historical detection period if the status detection indicator is greater than a status detection indicator threshold.Optionally, the processor may further execute program code for the following steps: counting the number of fluctuation queries executed during the fluctuation query operation and the total number of queries executed during the query operation; determining the ratio of the number of fluctuation queries to the total number of queries; and using the ratio as a status detection indicator for the database product. Optionally, the processor may further execute program code for the following steps: determining that the status detection indicator is greater than a status detection indicator threshold if the ratio is greater than a preset ratio threshold, where the status detection indicator threshold includes a ratio threshold. Optionally, the processor may further execute program code for the following steps: determining a query pattern matched by at least one query operation; determining a time threshold based on the query pattern. Optionally, the processor may further execute program code for the following steps: obtaining at least one historical query operation of the database product that matches the query pattern within a period prior to the historical detection period; determining the historical response time of the historical query operation; and determining a time threshold based on the historical response time. Optionally, the processor may further execute program code for the following steps: determining a target response time based on multiple historical response times corresponding to multiple historical query operations, where the target response time is used to describe the overall statistical results of the multiple historical response times; and determining a time threshold based on the target response time. Optionally, the processor may further execute program code for the following steps: determining an adjustment parameter based on the target response time, where the adjustment parameter is used to represent a multiple by which the target response time is adjusted; adjusting the target response time according to the adjustment parameter; and determining the adjusted target response time as the time threshold. Optionally, the processor may further execute program code for the following steps: determining a target abnormality indicator for the database product based on a state detection indicator corresponding to the abnormal stability state, where the target abnormality indicator is used to place the database product in an abnormal stability state. Optionally, the processor may further execute program code for the following steps: determining, based on the status detection indicator, an abnormal period during which the database product was in an abnormal stability state within a historical detection period; determining, based on the abnormal period, a period to be tested for a target abnormality indicator; determining the period to be tested as the historical detection period, and returning to execute from the following steps to obtain the status detection indicator within the period to be tested: obtaining at least one query operation to which the database product responded within the historical detection period; and determining the target abnormality indicator based on the status detection indicator within the period to be tested.Optionally, the processor may further execute program code for the following steps: obtaining candidate anomaly indicators for the database product during a test period, wherein the candidate anomaly indicators are indicators to be determined that place the database product in an abnormally stable state; obtaining a correlation between a state detection indicator during the test period and the candidate anomaly indicator, wherein the correlation indicates the degree of correlation between the state detection indicator during the test period and the candidate anomaly indicator; and, in response to the correlation being greater than a correlation threshold, determining the candidate anomaly indicator as a target anomaly indicator, wherein the target anomaly indicator is used to place the database product in an abnormally stable state. Optionally, the processor may further execute program code for the following steps: obtaining a first feature vector of the state detection indicator; obtaining a second feature vector of the candidate anomaly indicator; and determining the similarity between the first feature vector and the second feature vector as the correlation. Optionally, the processor may further execute program code for the following steps: determining a preceding period prior to the start time of the abnormal period; and determining the abnormal period and the preceding period as the test period. Optionally, the processor may further execute program code of the following steps: inputting the state detection indicator into a machine learning model for prediction to obtain a target abnormality indicator, wherein the machine learning model is trained based on the state detection indicator sample and the abnormality indicator sample of the database product, the state detection indicator sample is used to characterize the abnormal stability state of the database product, and the abnormality indicator sample is used to place the database product in the abnormal stability state corresponding to the state detection indicator sample. Embodiments of the present disclosure provide a database product status detection method that measures the stability of the database product using a status detection indicator. The status detection indicator is determined based on at least one fluctuating query operation and at least one query operation within a historical detection period. Therefore, the status detection indicator can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the database product status detection indicator is compared with a status detection indicator threshold. If the status detection indicator is greater than the status detection indicator threshold, it is determined that the database product is in an abnormally stable state. In other words, manual troubleshooting is unnecessary; using the status detection indicator threshold as a data reference, when the status detection indicator is greater than the status detection indicator threshold, it is automatically determined that the database product is in an abnormally stable state. This significantly reduces troubleshooting time when database product problems occur, provides a foundation for automated operation and maintenance of database products, improves user experience, and solves the technical problem of low database product status detection efficiency.Those skilled in the art will appreciate that the structure shown in FIG12 is merely illustrative, and the computer terminal may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. FIG12 does not limit the structure of the aforementioned electronic devices. For example, computer terminal A may include more or fewer components (such as a network interface, a display device, etc.) than those shown in FIG12 , or have a configuration different from that shown in FIG12 . Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program may be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Example 4: The present disclosure also provides a computer-readable storage medium. Optionally, in this embodiment, the storage medium may be used to store program code executed by the database product status detection method provided in the first embodiment. Optionally, in this embodiment, the storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group. Optionally, in this embodiment, the storage medium is configured to store program code for executing the following steps: obtaining at least one query operation responded to by the database product within a historical detection period; identifying at least one fluctuating query operation within the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold within the at least one query operation; determining a status detection indicator of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection indicator is used to characterize the stability state of the database product; and determining that the database product is in an abnormal stability state within the historical detection period if the status detection indicator is greater than the status detection indicator threshold. Embodiments of the present disclosure also provide a computer program product comprising computer instructions. When executed by a processor, the computer instructions implement the database product status detection method provided in the embodiments of the present disclosure.In this embodiment, the aforementioned computer instructions may be stored in a read-only memory (ROM) or loaded from a storage unit into a random access memory (RAM), enabling the processor to execute various appropriate actions and processes in the database product status detection method. In some embodiments, some or all of the aforementioned computer instructions may be loaded and / or installed on an electronic device via a read-only memory and / or a communication unit. When the computer instructions are loaded into the random access memory and executed by the computing unit, one or more steps in the database product status detection method described above may be performed. The serial numbers of the aforementioned embodiments of the present disclosure are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In the aforementioned embodiments of the present disclosure, the description of each embodiment has its own emphasis. For portions not detailed in a particular embodiment, reference should be made to the relevant descriptions of other embodiments. In the several embodiments provided in this disclosure, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. In actual implementation, other divisions may be employed. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces, or indirect couplings or communication connections between units or modules, and may be electrical or other. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of these units may be selected to achieve the objectives of the present embodiments based on actual needs. Furthermore, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. These integrated units may be implemented in either hardware or software functional units. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for causing a computer device (such as a personal computer, server, or network device) to execute all or part of the steps of the methods described in various embodiments of the present disclosure.The aforementioned storage media include various media capable of storing program code, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), removable hard drives, magnetic disks, or optical disks. The above descriptions are merely preferred embodiments of the present disclosure. It should be noted that those skilled in the art may make various improvements and modifications without departing from the principles of the present disclosure, and such improvements and modifications should be considered within the scope of protection of the present disclosure.

Claims

Claims 1. A method for detecting the status of a database product, which is applied to a cloud server on which a database product is deployed. The method includes: Obtaining at least one query operation responded by the database product within a historical detection period; Among the at least one query operation, at least one fluctuation query operation is identified, wherein the fluctuation query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; based on the at least one fluctuation query operation and the at least one query operation, a state detection index of the database product is determined, wherein the state detection index is used to characterize the stability state of the database product; if the state detection index is greater than a state detection index threshold, it is determined that the database product is in an abnormal stability state during the historical detection period.

2. According to the method described in claim 1, based on the at least one fluctuation query operation and the at least one query operation, determine the status detection index of the database product, including: Counting the number of fluctuation queries that execute the fluctuation query operation and the total number of queries that execute the query operation; determining the proportion of the number of fluctuation queries to the total number of queries; and using the proportion as the status detection indicator of the database product.

3. The method according to claim 2, the method further comprising: If the proportion is greater than a preset proportion threshold, it is determined that the state detection index is greater than the state detection index threshold, wherein the state detection index threshold includes the proportion threshold.

4. The method according to any one of claims 1 to 3, the method further comprising: Determining a query pattern matched by the at least one query operation; Based on the query mode, the time threshold is determined.

5. The method according to claim 4, wherein determining the time threshold based on the query pattern comprises: Acquire at least one historical query operation of the database product that matches the query pattern within a preset period before the historical detection period; Determining a historical response time of the historical query operation; Based on the historical response time, the time threshold is determined.

6. The method according to claim 5, determining the time threshold based on the historical response time, includes: Based on the multiple historical response times corresponding to the multiple historical query operations, a target response time is determined, wherein the target response time is used to describe the overall statistical result of the multiple historical response times; based on the target response time, the time threshold is determined.

7. The method according to claim 6, wherein determining the time threshold based on the target response time comprises: Based on the target response time, determining an adjustment parameter, wherein the adjustment parameter is used to represent a multiple of adjusting the target response time; adjusting the target response time according to the adjustment parameter; and determining the adjusted target response time as the time threshold.

8. The method according to any one of claims 1 to 7, the method further comprising: Based on the state detection indicator corresponding to the abnormal stability state, a target abnormality indicator of the database product is determined, wherein the target abnormality indicator is used to put the database product in the abnormal stability state.

9. The method according to claim 8, wherein determining a target abnormal index of the database product based on the state detection index corresponding to the abnormal stability state comprises: Based on the state detection indicator, determine that the database product is in the abnormal stability during the historical detection period. Abnormal periods of qualitative status; Based on the abnormal period, determining a time period to be tested for the target abnormal indicator; The time period to be tested is determined as the historical detection time period, and the following steps are returned to be executed to obtain the state detection index in the time period to be tested: obtaining the at least one query operation responded by the database product in the historical detection time period; Based on the state detection index within the time period to be tested, the target abnormality index is determined.

10. The method according to claim 9, determining the target abnormal index based on the status detection index within the period to be measured, includes: Obtain candidate abnormal indicators of the database product during the period to be measured, where the candidate abnormal indicators are indicators to be determined that put the database product in the abnormal stability state; obtain the correlation between the state detection indicators and the candidate abnormal indicators during the period to be measured, where the correlation is used to represent the degree of correlation between the state detection indicators and the candidate abnormal indicators during the period to be measured; in response to the correlation being greater than the correlation threshold, determine the candidate abnormal indicators as the target abnormal indicators.

11. For the method according to claim 10, obtaining the correlation between the status detection index and the candidate anomaly index during the period to be measured includes: Obtain the first feature vector of the state detection indicators; Obtain the second feature vector of the candidate abnormal indicators; determine the similarity between the first feature vector and the second feature vector as the correlation.

12. The method according to any one of claims 9 to 11, based on the abnormal period, determining a period to be measured for the target abnormal indicator, includes: Determine a pre-period before the start time of the abnormal period; Determine the abnormal period and the pre-period as the period to be measured.

13. The method according to claim 8, determining a target abnormal index of the database product based on the state detection index corresponding to the abnormal stability state, includes: Input the state detection indicators into a machine learning model for prediction to obtain the target abnormal indicators, where the machine learning model is trained based on state detection indicator samples and abnormal indicator samples of the database product, the state detection indicator samples are used to characterize the abnormal stability state of the database product, and the abnormal indicator samples are used to put the database product in the abnormal stability state corresponding to the state detection indicator samples.

14. A method for detecting the status of a database product, which is applied to a cloud server on which a database product is deployed, and the method includes: By calling a first interface, obtain at least one query operation responded by the database product during a historical detection period, where the first interface includes a first parameter, and the parameter value of the first parameter is the at least one query operation; in the at least one query operation, identify at least one fluctuating query operation, where the fluctuating query operation is a query in the at least one query operation whose response time exceeds a time threshold; based on the at least one fluctuating query operation and the at least one query operation, determine the state detection indicators of the database product, where the state detection indicators are used to characterize the stability state of the database product; if the state detection indicators are greater than the state detection indicator threshold, then determine that the database product is in an abnormal stability state during the historical detection period; output a prompt message of the abnormal stability state by calling a second interface, where the second interface includes a second parameter, and the parameter value of the second parameter is the prompt message of the abnormal stability state.

15. A state detection system for a database product, comprising: A client for uploading a state detection instruction of the database product; A cloud server for, in response to the state detection instruction, obtaining at least one query operation responded by the database product during a historical detection period; In the at least one query operation, identify at least one fluctuating query operation, where the fluctuating query operation is a query in the at least one query operation with a response time exceeding a time threshold; based on the at least one fluctuating query operation and the at least one query operation, determine a status detection index of the database product, where the status detection index is used to characterize the stability state of the database product; if the status detection index is greater than a status detection index threshold, determine that the database product is in an abnormal stability state during the historical detection period; and return a prompt message of the abnormal stability state to the client.

16. An electronic device, comprising: A memory storing an executable program; A processor for running the program, where when the program runs, it executes the method according to any one of claims 1 to 14.

17. A computer-readable storage medium, the computer-readable storage medium comprising a stored program, wherein, When the program runs, control the device where the storage medium is located to execute the method according to any one of claims 1 to 14.

18. A computer program product comprising computer instructions that, when executed by a processor, implement the method according to any one of claims 1 to 14.

Images