Method, device and electronic equipment for verifying validity of a plan tree in a database

Abstract

The application relates to a method and device for verifying the validity of a plan tree in a database. The method comprises the following steps: when persisting a query plan tree, storing the query plan tree corresponding to an SQL ID, a normalized SQL text, a dependent object OID and a changeCSN in a system table; when multiplexing, obtaining the plan tree and the associated information through the SQL ID, and sequentially performing text comparison, dependent object OID comparison and changeCSN version comparison; if any comparison fails, the plan is determined to be invalid. The method solves the plan tree invalidation problems caused by SQL ID collision, cross-table same-name object interference and dependent object DDL change through the triple mechanism of SQL text matching, dependent object OID verification and changeCSN change detection, ensures that the solidified plan is always consistent with the current mode, guarantees the safety and execution correctness of the persistent plan tree multiplexing, and has the advantages of convenient development and wide adaptability.

Description

Technical Field

[0001] This application relates to the field of database operation technology, and in particular to a method, apparatus, computer-readable storage medium, and electronic device for verifying the validity of a plan tree in a database. Background Technology

[0002] In the field of database query optimization technology, the core of query execution relies on the synergistic effect of key technologies such as query plan tree, SQL identifier (SQLID), plan solidification mechanism and database object change tracking.

[0003] 1. Query plan tree A query plan tree is a structured execution blueprint generated by the relational database query optimizer after performing syntax parsing, semantic analysis, logical optimization, and physical optimization on SQL query statements. It represents the complete process of data processing by the database engine in the form of a tree data structure, including key elements such as the execution order, access path, and statistical information of each operator (such as scan, join, sort, etc.). It is the internal core instruction set that guides query execution.

[0004] 2. SQL ID SQL IDs are unique identifiers generated based on SQL statement characteristics (such as text hash values, normalized syntax structures, etc.) and are used to represent the logical semantics of SQL statements. Normally, the same SQL text will generate the same SQL ID; however, due to the inherent characteristics of hash algorithms, different SQL texts may also generate the same SQL ID (i.e., hash collisions). Although the probability of a collision is extremely low, it is theoretically impossible to completely avoid it. SQL IDs serve as the associated index for query plans and play a crucial role in scenarios such as plan caching and execution strategy matching.

[0005] 3. Plan solidification Query plan binding is an advanced feature supported by database management systems (DBMS) that allows database administrators (DBAs) or developers to forcibly bind specific SQL statements (usually identified by SQL IDs) to a predefined query plan tree. This mechanism ensures that the target SQL always executes along the optimal or preset execution path, avoiding the performance overhead of repeated parsing and optimization, while guaranteeing the execution stability of complex queries or critical business operations.

[0006] 4. database object changeCSN In databases like OpenGauss, the system table `pg_object` records metadata information about database objects. The `createCSN` field marks the transaction commit sequence number (CSN) when the object was first created, and the `changeCSN` field is updated synchronously when the object is updated via DDL (Data Definition Language) operations (such as `ALTER TABLE`, `DROP INDEX`, etc.). Essentially, `changeCSN` is a transaction-level timestamp of the object's structural changes; by comparing this field, one can accurately determine whether a database object has undergone structural modifications.

[0007] Limitations of existing technology In openGauss and similar database systems, plan persistence is typically achieved by serializing the query plan tree into a string format, storing it in a system table, and establishing a relationship with the corresponding SQL ID. The plan tree can then be retrieved via the SQL ID, deserialized, and directly used for query execution, thus supporting scenarios such as plan persistence, backup, and recovery. However, existing technologies have the following key drawbacks: (1) Lack of validity verification mechanism for persistent plan trees: For plan trees in memory, the database can mark them as invalid through data dictionary invalidation mechanism (such as cache invalidation triggered by metadata changes of dependent objects); however, for plan trees in persistent storage (such as plan trees serialized in system tables), the existing technology does not provide a means to verify their validity.

[0008] (2) Potential risk of incorrect execution: When an SQL ID hash collision occurs (different SQL texts are mapped to the same ID) or the database objects on which the plan tree depends (such as table structure, indexes, etc.) are updated (manifested as a changeCSN change), the historical plan tree retrieved by the original SQL ID may not match the current SQL semantics or object structure. If such a failed plan tree is used directly to execute a query, it may lead to serious problems such as incorrect execution results, performance degradation, or even data inconsistency.

[0009] In summary, there is an urgent need for a validity verification method for persistent plan trees to solve the problem of plan tree failure caused by SQLID collisions or changes in dependent objects in existing technologies, and to ensure the correctness and reliability of query execution. Summary of the Invention

[0010] To address the aforementioned problems in existing technologies, this application proposes a novel method for verifying the validity of a plan tree in a database. This invention extracts a set of key feature data from a query tree based on SQL statements and combines this data with SQL text to implement a set of methods for verifying the validity of the plan tree, thereby supporting the reuse of persistent plan trees.

[0011] In summary, this application verifies whether the query plan tree obtained from the SQL ID matches the SQL ID through the following multiple mechanisms, that is, verifies whether the obtained query plan tree is valid: 1. When persisting the plan tree, the corresponding SQL text is also saved, and the OID of the dependent database objects and the changeCSN information at that time are extracted from the corresponding query tree, mainly including relations, stored procedures and operators; 2. When retrieving the corresponding query plan tree from the system table using the SQL ID, simultaneously retrieve the SQL text of the plan tree, the OID information of the dependent objects, and the changeCSN information; 3. Verify whether the current SQL text matches the SQL text corresponding to the query plan tree, thereby resolving the situation where other SQL statement query plan trees are incorrectly obtained in the event of SQL ID collision; 4. Verify whether the dependency objects of the current SQL are the same as the dependency objects corresponding to the query plan tree, so as to resolve the situation where other SQL statement query plan trees are incorrectly obtained when SQLID collision and SQL text are also the same; 5. Verify whether the changeCSN of the dependent objects of the current query plan tree has been modified by DDL, in order to resolve the situation where the plan tree becomes invalid after the dependent objects have been deleted or updated.

[0012] Specifically, this application provides the following technical solutions: A first aspect of this application provides a method for validating the validity of a plan tree in a database, the method comprising: S1. During the query plan tree persistence phase, the query plan tree of the SQL statement, the normalized SQL text, and the OIDs and transaction commit sequence numbers changeCSNs of the dependent objects extracted from the query plan tree are written to the system table and associated with the SQL ID; S2. In the query plan tree reuse phase, the corresponding query plan tree is obtained from the system table by the target SQL ID, and the associated stored SQL text, the OID of the dependent object and the changeCSN information are also obtained. S3. Normalize the current SQL text to be verified, and compare the processed current SQL text with the associated stored SQL text; if they do not match, the query plan tree is determined to be invalid. S4. If a match is found in S3, compare the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage; if they do not match, the query plan tree is deemed invalid. S5. If the results in S4 are consistent, obtain the latest changeCSN information of the current dependent object and compare it with the changeCSN information in the associated storage; if there is a change, determine that the query plan tree is invalid; if there is no change, determine that the query plan tree is valid.

[0013] Furthermore, in the method of this application, the normalization process described in steps S1 and S3 includes: deleting comments, deleting hints, deleting spaces and whitespace characters, and maintaining consistent capitalization of keywords.

[0014] Furthermore, in the method of this application, the dependent object includes at least one of the three types of database objects: relational, stored procedure, and operator.

[0015] Furthermore, in the method of this application, the step S4 of comparing the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage includes verifying the number of dependent objects and whether the OIDs of each object are the same.

[0016] Furthermore, in the method of this application, the system table is a system table in the openGauss database used to store query plan trees and associated metadata, and the changeCSN information is obtained from the pg_object system table of the database.

[0017] A second aspect of this application provides an apparatus for validating the validity of a plan tree in a database, the apparatus comprising: The associated storage module is used to write the query plan tree of the SQL statement, the normalized SQL text, and the OIDs and transaction commit sequence numbers changeCSNs of the dependent objects extracted from the query plan tree into the system table during the query plan tree persistence phase, and associate them with the SQL IDs. The information reading module is used to retrieve the corresponding query plan tree from the system table by the target SQL ID during the query plan tree reuse phase, and at the same time retrieve the associated stored SQL text, the OID of the dependent object and the changeCSN information. The text comparison module is used to normalize the current SQL text to be verified, and compare the processed current SQL text with the associated stored SQL text; if they do not match, the query plan tree is determined to be invalid. The object comparison module is used to compare the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage; if they are inconsistent, the query plan tree is determined to be invalid. The version comparison module is used to obtain the latest changeCSN information of the current dependent object and compare it with the changeCSN information in the associated storage; if there is a change, the query plan tree is determined to be invalid; if there is no change, the query plan tree is determined to be valid.

[0018] The device implements the steps of the aforementioned method for verifying the validity of the plan tree in the database during operation.

[0019] Furthermore, the device of this application also includes: The decision module is used to mark the query plan tree as valid and deliver it for execution when all comparisons pass; otherwise, it is marked as invalid and a re-optimization is triggered.

[0020] Furthermore, in the device of this application, the text comparison module, object comparison module and version comparison module are executed serially in a pipeline manner, and the subsequent comparison is terminated when any module outputs an invalid result.

[0021] A third aspect of this application provides an electronic device, including: a memory and a processor; Memory: Used to store computer programs; Processor: Used to execute the computer program to implement the steps of the aforementioned method for verifying the validity of the plan tree in the database.

[0022] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned method for verifying the validity of a plan tree in a database.

[0023] In summary, compared with the prior art, the solution of this application has the following advantages: (1) Highly efficient development adaptability This solution fully leverages the core capabilities built into the database, relying on the database's native query tree parsing mechanism to directly obtain a structured representation of the SQL execution plan. Simultaneously, it combines the ability to extract dependency object information implicitly within the query tree with a database object DDL change detection mechanism based on changeCSN (transaction commit sequence number), enabling efficient identification and modification status verification of dependency objects. This organic integration of capabilities significantly reduces the complexity and cost of feature development, and provides rapid integration and deployment.

[0024] (2) Wide range of scene compatibility and scalability This application's verification mechanism is highly universal and can be seamlessly adapted to all modules or plugins in databases such as openGauss that extend functionality based on query plan trees. To meet specific business needs, it supports the selection of differentiated persistence strategies (such as system table storage or external file storage) for key information such as the query plan tree ontology, dependent object metadata, and original SQL text. This solution reliably determines whether the persisted query plan tree matches the current database object state and SQL semantics, effectively ensuring the execution security and result correctness of extended functions such as plan persistence and backup / recovery.

[0025] Other features and advantages of this application will be set forth in detail in the following description, or will become apparent through the implementation of the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved through the technical features and means explicitly pointed out in the description, claims, and drawings, and will be obtained through the implementation of these technical contents. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings involved in the description of the embodiments will be briefly introduced below. It should be noted that the accompanying drawings only show some embodiments of this application. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0027] Figure 1 This is a flowchart illustrating the overall implementation of the method for validating the plan tree in the database of this application.

[0028] Figure 2 This is a structural diagram of the apparatus for verifying the validity of the plan tree in the database of this application.

[0029] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0031] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0032] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0033] Figure 1 The diagram shows the overall implementation flow of the method for verifying the validity of a plan tree in the database provided in this application, including the following steps: S1. During the query plan tree persistence phase, the query plan tree of the SQL statement, the normalized SQL text, and the OIDs and transaction commit sequence numbers changeCSNs of the dependent objects extracted from the query plan tree are written to the system table and associated with the SQL ID; S2. In the query plan tree reuse phase, the corresponding query plan tree is obtained from the system table by the target SQL ID, and the associated stored SQL text, the OID of the dependent object and the changeCSN information are also obtained. S3. Normalize the current SQL text to be verified, and compare the processed current SQL text with the associated stored SQL text; if they do not match, the query plan tree is determined to be invalid. S4. If a match is found in S3, compare the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage; if they do not match, the query plan tree is deemed invalid. S5. If the results in S4 are consistent, obtain the latest changeCSN information of the current dependent object and compare it with the changeCSN information in the associated storage; if there is a change, determine that the query plan tree is invalid; if there is no change, determine that the query plan tree is valid.

[0034] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0035] This embodiment uses the openGauss database as an example. First, the semantic processing module of the openGauss database is configured to extract the dependent object OID information and changeCSN information when generating the query tree, and record the SQL text. Subsequently, based on this information, the validity of the query plan tree obtained through the SQL ID is verified. 1. When persisting the plan tree, record the SQL text, the OID information of dependent objects, and the changeCSN information simultaneously.

[0036] (1) When the plan tree needs to be persisted, the corresponding SQL text is also recorded; when accessing the plan tree later, the validity of the query plan tree is verified by verifying whether the SQL text matches. (2) Extract the OID and changeCSN information of the dependent objects from the query tree and persist them.

[0037] Some operations in the openGauss database can modify the attribute information of database objects without changing the SQL text content. This can lead to a situation where even if the SQL text matches perfectly, there will still be SQL ID collisions, and the actual query plan tree will be completely different.

[0038] This solution extracts the OID and changeCSN information of dependent objects from the query tree. These dependent objects mainly include relations, stored procedures, and operators. The above information is persisted to the system table along with the query plan tree. Subsequently, the validity of the query plan tree can be verified based on this information.

[0039] 2. When using a persistent query plan tree, first find the matching query plan tree by SQL ID, and at the same time obtain its corresponding SQL text and dependency object information, and then perform validity verification.

[0040] (1) Verify whether the normalized SQL text is the same. When SQL IDs collide, the corresponding SQL texts are usually different, such as only the literals in the SQL statements being different. In this case, you can quickly check whether the obtained query plan tree is valid by comparing the SQL texts. Since spaces, comments, and other elements in SQL statements do not affect the semantics of the SQL statements, and these elements are usually ignored when generating SQL IDs, the SQL text should be normalized as follows when verifying whether the SQL text matches: a) Remove spaces and whitespace characters from the SQL text; b) Remove comment information from the SQL text; c) Remove hint information from the SQL text.

[0041] (2) Verify whether the dependent object information is the same Because openGauss supports cross-schema operations, if objects with the same name are created under different schemas, the SQL text may be identical; in this case, the SQL IDs will collide, and they will actually correspond to different query plan trees.

[0042] By comparing the dependency object information extracted from the current query SQL with the dependency object information of the persistent query plan tree, this situation can be detected, thus preventing access to the wrong query plan tree when SQL IDs collide.

[0043] This step mainly involves comparing the number of dependent objects and whether their OIDs are the same.

[0044] (3) Verify whether the dependent objects are valid. After completing the above verification, it can be ensured that the current SQL statement (SQL ID) and the obtained query plan tree are a complete match. However, it cannot be guaranteed that the obtained query plan tree is valid. For example, if the dependent view is recreated, the function used in the SQL statement is recreated, or the type of the dependent table class is modified, it is still necessary to check whether the dependent object is valid.

[0045] In the openGauss database, DDL modifications to database objects are recorded in the system table `pg_object` with a `changeCSN` field to mark the CSN number of the committed transaction that modified the object. The latest object's `changeCSN` is obtained by retrieving the dependency object OID saved during the persistence plan tree and compared with the `changeCSN` saved during persistence. If a change has occurred, it indicates that a DDL operation has been performed on the object, thus determining that the query plan tree has become invalid.

[0046] Figure 2 The image shows an apparatus for verifying the validity of a plan tree in a database, as proposed in this application. The apparatus includes: The associated storage module is used to write the query plan tree of the SQL statement, the normalized SQL text, and the OIDs and transaction commit sequence numbers changeCSNs of the dependent objects extracted from the query plan tree into the system table during the query plan tree persistence phase, and associate them with the SQL IDs. The information reading module is used to retrieve the corresponding query plan tree from the system table by the target SQL ID during the query plan tree reuse phase, and at the same time retrieve the associated stored SQL text, the OID of the dependent object and the changeCSN information. The text comparison module is used to normalize the current SQL text to be verified, and compare the processed current SQL text with the associated stored SQL text; if they do not match, the query plan tree is determined to be invalid. The object comparison module is used to compare the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage; if they are inconsistent, the query plan tree is determined to be invalid. The version comparison module is used to obtain the latest changeCSN information of the current dependent object and compare it with the changeCSN information in the associated storage; if there is a change, the query plan tree is determined to be invalid; if there is no change, the query plan tree is determined to be valid.

[0047] The above-described apparatus implements the steps of the method for verifying the validity of the plan tree in the database disclosed in this application when it is in operation.

[0048] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of apparatus, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0049] like Figure 3 As shown in the illustration, an embodiment of this application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the method described above for verifying the validity of a plan tree in a database.

[0050] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0051] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types: Object-oriented programming languages, such as Java, Smalltalk, C++, etc. Conventional procedural programming languages, such as "C" or similar programming languages.

[0052] The execution methods of program code include, but are not limited to: It runs entirely on the user's computer; Part of it executes on the user's computer, and part of it executes on a remote computer; Execute as a standalone software package; It is executed entirely on a remote computer or server.

[0053] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers through an internet service provider, for example, by utilizing the internet for connection.

[0054] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the steps of the method for verifying the validity of a plan tree in a database disclosed in this application.

[0055] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following: (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0056] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0057] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0058] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0059] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0060] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0061] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0062] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0063] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0064] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0065] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0066] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for performing a method for verifying the validity of a plan tree in a database disclosed in this application. When this computer program is executed by a processing device, it can achieve the functions defined in the embodiments of this application.

[0067] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0068] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for validating the validity of a plan tree in a database, characterized in that, The method includes: S1. During the query plan tree persistence phase, the query plan tree of the SQL statement, the normalized SQL text, and the OIDs and transaction commit sequence numbers changeCSNs of the dependent objects extracted from the query plan tree are written to the system table and associated with the SQL ID; S2. In the query plan tree reuse phase, the corresponding query plan tree is obtained from the system table by the target SQL ID, and the associated stored SQL text, the OID of the dependent object and the changeCSN information are also obtained. S3. Normalize the current SQL text to be verified, and compare the processed current SQL text with the associated stored SQL text; if they do not match, the query plan tree is determined to be invalid. S4. If a match is found in S3, compare the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage; if they do not match, the query plan tree is deemed invalid. S5. If the results in S4 are consistent, obtain the latest changeCSN information of the current dependent object and compare it with the changeCSN information in the associated storage; if there is a change, determine that the query plan tree is invalid; if there is no change, determine that the query plan tree is valid.

2. The method according to claim 1, characterized in that, The normalization process described in steps S1 and S3 includes: deleting comments, deleting hints, deleting spaces and whitespace characters, and maintaining consistent capitalization of keywords.

3. The method according to claim 1, characterized in that, The dependent objects include at least one of the three types of database objects: relations, stored procedures, and operators.

4. The method according to claim 1, characterized in that, The step S4, which compares the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage, includes verifying the number of dependent objects and whether the OIDs of each object are the same.

5. The method according to claim 1, characterized in that, The system table is a system table in the openGauss database used to store query plan trees and associated metadata. The changeCSN information is obtained from the pg_object system table in the database.

6. An apparatus for validating the validity of a plan tree in a database, characterized in that, include: The associated storage module is used to write the query plan tree of the SQL statement, the normalized SQL text, and the OIDs and transaction commit sequence numbers changeCSNs of the dependent objects extracted from the query plan tree into the system table during the query plan tree persistence phase, and associate them with the SQL IDs. The information reading module is used to retrieve the corresponding query plan tree from the system table by the target SQL ID during the query plan tree reuse phase, and at the same time retrieve the associated stored SQL text, the OID of the dependent object and the changeCSN information. The text comparison module is used to normalize the current SQL text to be verified, and compare the processed current SQL text with the associated stored SQL text; if they do not match, the query plan tree is determined to be invalid. The object comparison module is used to compare the OID set of the dependent objects of the current SQL with the OID set of the dependent objects in the associated storage; if they are inconsistent, the query plan tree is determined to be invalid. The version comparison module is used to obtain the latest changeCSN information of the current dependent object and compare it with the associated stored changeCSN information; If any changes occur, the query plan tree is deemed invalid. If no changes occur, the query plan tree is considered valid.

7. The apparatus according to claim 6, characterized in that, The device also includes: The decision module is used to mark the query plan tree as valid and deliver it for execution when all comparisons pass; otherwise, it is marked as invalid and a re-optimization is triggered.

8. The apparatus according to claim 6, characterized in that, The text comparison module, object comparison module, and version comparison module are executed sequentially in a pipeline manner, and the subsequent comparison is terminated if any module outputs an invalid result.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method for verifying the validity of a plan tree in a database as described in any one of claims 1-5.

10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the method for validating the validity of the plan tree in the database as described in any one of claims 1-5.

Images