Operator combination based sql generation method for database kernel testing

Abstract

The application relates to the field of database testing, and discloses an SQL generation method based on operator combination for database kernel testing, which comprises the following steps: defining a group of database query execution operators, generating a query plan tree based on the combination of the operators, and automatically constructing an effective SQL query statement, and the method is particularly suitable for testing of database function expansion, especially when new functions are introduced and compatible with original functions, and the method can efficiently detect whether the introduction of new functions has an impact on the original functions, performance and stability of the database, and help verify the correctness and compatibility of the expanded functions of the database. The method improves the testing efficiency, expands the testing coverage, and ensures that the new functions do not introduce unnecessary side effects or performance problems in the process of database function expansion.

Description

Technical Field

[0001] This invention relates to the field of database testing technology, and in particular to a SQL generation method based on operator combination for database kernel testing. Background Technology

[0002] In the development and optimization of database kernels, extensive testing is often required to verify the stability, performance, and correctness of new versions. Traditional testing methods typically rely on manually writing SQL queries or using random SQL generation tools (such as SQLsmith). However, these tools often generate statements that lack specificity and semantic control, and their execution path coverage is limited, making it difficult to meet the comprehensive coverage requirements of database kernel testing for complex query scenarios.

[0003] To address the aforementioned issues, this invention proposes a random query plan generation method based on an operator library. This method randomly generates a query plan tree by combining operators and then converts it into SQL queries. This approach expands the comprehensiveness of testing and, by controlling the relationships between operators, ensures that the generated SQL queries have practical execution meaning, thus enabling the detection of potential database defects. Summary of the Invention

[0004] This invention aims to at least solve one of the technical problems existing in related technologies. To this end, this invention provides a SQL generation method based on operator combination for database kernel testing.

[0005] A method for generating SQL based on operator combination for database kernel testing, comprising the following steps:

[0006] S1, extract metadata from the target database and build an operator library;

[0007] S2, retrieve test configuration and generate test constraints.

[0008] The test constraints include at least one of the following: limiting specific operators to be included in the query plan tree, limiting the minimum or maximum number of tables accessed in the database, limiting access to specific tables, limiting the data types included in the output results, limiting the number of specific operators to a threshold, and limiting the depth threshold of the query plan tree.

[0009] S3. Based on the operator library and the metadata, a query plan tree is generated recursively. Each node of the query plan tree is an operator, and the edges between nodes represent the dependencies between operators. The generated query plan tree satisfies the test constraints.

[0010] S4. Generate an SQL query from top to bottom based on the metadata and the query plan tree;

[0011] S5, Execute the SQL query on the target database, monitor the behavior during the execution process, and generate the execution results of the database test. The execution results include the execution status, exception information, execution time, and resource consumption.

[0012] S6, record the SQL query and execution results, and generate a structured test result dataset for subsequent reproduction, regression testing and coverage analysis.

[0013] Furthermore, the metadata in S1 is obtained by querying the system directory of the target database, which includes table structure information;

[0014] The metadata includes table definitions, data type definitions, operator definitions, function definitions, and type conversion rules. This metadata is used to ensure type compatibility during query plan tree generation and SQL query generation.

[0015] Furthermore, the test configuration includes:

[0016] The functional modules of the database under test, the coverage targets of specific operators, the maximum depth of the query plan tree, and special strategies.

[0017] Furthermore, the operator library includes scanning operators, filtering operators, connection operators, aggregation operators, sorting operators, restriction operators, and common expression operators;

[0018] Operators in the operator library have defined input-output structures;

[0019] Scan operators scan data in a table and output rows; filter operators filter data based on specific conditions and output rows that meet the conditions; join operators join two result sets and output randomly selected columns; aggregation operators perform aggregation operations on the input result set and output a single result or a result set; sort operators sort the input result set and output the sorted result set; limit operators limit the number of output results; common expression operators generate named temporary result sets.

[0020] Furthermore, query plan tree generation in S3 includes:

[0021] Based on the testing requirements, select an operator from the operator library as the current node of the query plan tree, prioritizing scan operators, join operators, filter operators, or common expression operators;

[0022] Based on the input requirements of the current node, select the matching sub-operator and recursively generate one or more child nodes for it until the preset termination condition is reached, wherein the output structure of the child node matches the input structure required by the operator of the current node as the query plan tree.

[0023] Recursively construct subtrees until the depth of the query plan tree is reached, according to the preset threshold.

[0024] After the child nodes of the current node are generated, the output column attributes of the current node are determined based on the output column information traced back from the child nodes, and the conditions or operations to be executed by the operator of the current node as the query plan tree are generated.

[0025] The output columns are all columns of the lower subtree or randomly selected columns, and ambiguity is eliminated by aliases;

[0026] The scan operator supports at least one of the following: basic table scan, materialized view scan, subquery scan, function return table scan, and outer table scan.

[0027] Furthermore, S3 also includes adding aggregation operators, sorting operators, and restriction operators to the query plan tree;

[0028] After the aggregation operator is generated, sorting operators and restriction operators can be further added to form a variety of combinations;

[0029] It also includes performing function operations or type conversions on the output columns of the query plan tree, wherein the function operations are based on function definitions in the metadata, and the type conversions are based on type conversion rules in the metadata.

[0030] Furthermore, SQL queries in S4 include SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, and LIMIT clauses;

[0031] SQL query generation includes:

[0032] Map the scan operators in the query plan tree to FROM clauses;

[0033] Map the filter operator to a WHERE clause;

[0034] Map the join operator to a JOIN statement or a WHERE condition;

[0035] Map aggregation operators to GROUP BY clauses and aggregation functions;

[0036] Map sorting operators to ORDER BY clauses;

[0037] Map the restriction operator to a LIMIT clause;

[0038] Map public expression operators to WITH clauses.

[0039] Furthermore, the monitoring of behavior during the execution process in S5 includes at least one of the following situations: syntax or semantic errors, system crashes, execution suspension, deadlocks, memory overflows, and error messages in the logs.

[0040] Furthermore,

[0041] The test result dataset includes the following information: original SQL content, execution result, execution time, resource consumption, triggered error type, and hit test target.

[0042] Application scenarios include at least one of the following: database kernel testing, performance regression testing, database optimizer testing, and integration with automated testing tools.

[0043] Furthermore, the operator library supports expansion. When the target database introduces new operators or query syntax, the generation probability of the corresponding operators is increased to verify the compatibility and stability of the new operators.

[0044] The query plan tree can be embedded into other query plan trees as subqueries or common expressions to form a nested query structure;

[0045] The SQL generation method is applicable to a variety of relational databases, including PostgreSQL, MySQL, openGauss, and Oracle, and adapts to the characteristics of different databases through the metadata.

[0046] The above-described one or more technical solutions in the embodiments of the present invention have at least one of the following technical effects:

[0047] The method of this invention is universal and applicable to the development and testing of various database kernels. In particular, it can effectively detect the impact of updates on database performance and correctness during the development and optimization of database kernels such as PostgreSQL, MySQL, openGauss, and Oracle.

[0048] The method of this invention can automatically generate SQL queries that meet execution requirements and is applicable to various tests of the database kernel, including performance testing, stability verification, and regression testing.

[0049] By controlling the combination of operators and the generation of execution plans, this invention can systematically detect potential problems in the database kernel without relying on manually writing SQL queries, thereby improving the database's test coverage and efficiency.

[0050] In terms of improving test coverage: The query plan tree generated based on operator combination can cover multiple execution paths of the database optimizer and execution engine, thereby improving test coverage.

[0051] Regarding automated SQL query generation: SQL queries are generated through algorithms, reducing manual intervention and improving testing efficiency.

[0052] Flexible test generation: It can generate diverse queries based on the operators supported by the database, adapting to complex database kernel testing needs.

[0053] Regarding change impact analysis: By analyzing the execution plans of different database versions, the impact of database updates on performance and stability can be quantified.

[0054] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0056] Figure 1 This is the main flow of the SQL generation method based on operator combination for database kernel testing according to the present invention;

[0057] Figure 2 This is the execution plan diagram for multi-table join queries in the database of this invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention. The following embodiments are used to illustrate this invention but should not be used to limit the scope of this invention.

[0059] Figure 1 The main flow of the SQL generation method based on operator combination for database kernel testing of this application is shown.

[0060] Figure 2 The structure of a database multi-table join query execution plan according to an embodiment of this application is shown.

[0061] The following will combine Figure 1 and Figure 2 The technical solution of this application is described in detail.

[0062] 1. Definition and classification of operator libraries

[0063] This invention first defines a set of database query execution operators, each of which can have different input and output structures, including but not limited to the following:

[0064] Scan operators: used to scan data in a table, such as Seq Scan, Index Scan, etc., outputting rows in a table, and performing function operations on these columns;

[0065] Filtering operators: used to filter data, based on specific conditions, such as Filter, and output rows that meet the filtering conditions;

[0066] Join operators: used to join different datasets, such as left join, right join, inner join, etc. The input is two result sets (which can be tables, views, subqueries or other operators' outputs), and the output is a series of randomly selected columns from the join objects. You can also perform some function operations on these columns.

[0067] Aggregation operators: used to perform aggregation operations on data, such as SUM, COUNT, AVG, etc. The input is the query result set, and the output is a single result or result set after aggregation calculation.

[0068] Sorting operators: used to sort data, such as ORDER BY, where the input is the query result set and the output is the sorted result set;

[0069] Limiting operators: used to limit the number of results returned, such as LIMIT, which returns a specified number of rows from the input result set;

[0070] Common Table Expression (CTE) is a named temporary result set defined using the WITH clause.

[0071] Other operators: Output the query result set, or output the result set after specific operations.

[0072] 2. Generate query plan tree

[0073] The method of this invention generates a query plan tree "randomly" based on a predefined operator library in a recursive manner. Each operator forms a query plan tree through combinations with its child operators. Each node in the tree represents an operator, and the structure of the tree represents the dependencies between operators.

[0074] The process of generating a query plan tree includes the following steps:

[0075] The plan tree is generated recursively from top to bottom. After the subtree below the current node is completely determined, the output column type and column name of the current node can be determined. All return columns of the subtree below can be returned, or some columns can be randomly selected as the return. If necessary, aliases will be used for tables, subqueries, function operations, etc. to eliminate ambiguity.

[0076] Randomly select an operator from the operator library. The most important one is actually the connection operator, which can connect two different scan operators, connection operators, common expressions, etc.

[0077] When selecting operators, priority is given to generating plan trees related to scanning, joining, filtering, and common expressions. The remaining operations are added on top of a basic plan tree after it has been generated.

[0078] Select appropriate input operators for each operator, following the input requirements of the operator above and matching them with the output of the operator below.

[0079] For example, Join requires two inputs, while Aggregate requires one input.

[0080] Recursively construct the query plan tree until the preset tree depth is reached.

[0081] Once the depth of the planning tree reaches a preset threshold, it will no longer be expanded further to prevent the planning tree from becoming too deep.

[0082] It should be noted that the testing requirements here are customized for the testing objectives. The essential goal is to make the generation logic "controllable and purposeful" rather than completely "random".

[0083] The generated plan tree covers, but is not limited to:

[0084] The plan tree contains one or more operators that you want to verify, covering the target operator;

[0085] The number of tables involved in the plan tree reaches a preset number, or the number of a certain operator reaches a threshold;

[0086] The plan tree contains a specific table;

[0087] The output contains a specific type to override any newly added type;

[0088] The expression contains a specific type or a specific operator.

[0089] Compared with traditional SQL generation methods based on random combination or exhaustive strategies, this mechanism is driven by the path to be verified or the test target, generating SQL with clear verification value, effectively avoiding the generation of duplicate paths, and improving the coverage and testing efficiency of statements.

[0090] After constructing a plan tree containing nodes for joining, filtering, etc., aggregation operators, sorting operators, and constraint operators are added to the result of this plan tree. Aggregation operators are added first, followed by sorting and constraint operators. These operators are added selectively; during actual execution, all combinations of adding and not adding operators will be selected.

[0091] To facilitate SQL generation, each scan operator, join operator, and common expression node records the name, data type, and attribute information of its output columns. In addition, it may contain information on functions that can be generated based on these columns.

[0092] Since table scans only occur at leaf nodes, all table metadata needs to be traced back from the bottom up. During this backtracking, for each join operator, the join condition is selected based on the information returned by its child operators, with the target test predicate being prioritized. During backtracking, output columns are uniformly named and aliased to eliminate ambiguity.

[0093] Each join operator can represent a join between two base tables or a join between two intermediate join results. The generation of join conditions follows this process: First, randomly select one attribute column from each of the left and right inputs; then, based on the data type of the attribute, filter out operators with compatible parameter types from the set of comparison operators supported by the database (such as those defined in the pg_operator system table in PostgreSQL); finally, select one operator from these (preferably the operator used for the target test, or randomly) to construct a semantically valid join condition.

[0094] Function operations can be performed on one or more columns returned by the current node, and aliases can be assigned to the function output to prevent naming conflicts. For example, if there is a function `func1(int, text)` and the output is (c1 int, c2int, c3 text, c4 text), then function parameters can be matched by type to generate functions such as `func1(c1, c3)` or `func1(c2, c3)`. Considering that databases can also perform type conversions, such as converting `int` to `text`, function operations such as `func1(c1, c2)` can also be generated. Function operations can be nested, such as `func2(func1(c1, c2))`.

[0095] Type conversions are generally defined in database system tables. For example, pg is defined in pg_cast. Implicit conversions can be used directly, while explicit conversions must be specified explicitly. For example, pg can use the "::" operator or cast(... as ...). In actual implementation, you can query the system tables to determine which types can be converted to the target type.

[0096] The generated plan tree can be used as a subquery or a common expression, or as a subtree of other plan trees.

[0097] It is worth noting that the scan operator, as the starting point of the data flow in the execution plan, directly impacts the coverage of test cases due to the diversity of its input data. Although the core of this method is not the data generation process itself, to ensure the completeness and effectiveness of the tests, we still focus on the characteristic coverage of the input data source, including but not limited to the diversity of data types (such as scalars, arrays, enumerations, custom composite types, etc.), the scale of data volume (small datasets, large datasets, empty datasets), and boundary value cases (such as maximum / minimum values, NULL, extreme distributions).

[0098] Furthermore, when constructing a plan tree, it is necessary to first consider the different forms of data sources, such as:

[0099] Basic table scan (SeqScan / IndexScan): covers different types of physical table structures and index structures;

[0100] Materialized View Scan: Verify the integration of pre-calculated results in the planning tree;

[0101] Subquery Scan: Used to generate plans for scenarios such as nested queries and CTEs;

[0102] Function Scan: Supports scanning and combining results of Set-Returning Functions (SRFs).

[0103] Foreign Table / Foreign Data Source Scan: Used to simulate the planned integration of heterogeneous data sources such as Federated Query and FDW.

[0104] Therefore, it is necessary to construct scan operators and predetermine the set of base tables that can be used to generate SQL. This set can be defined in the following ways: limiting it to all tables in a specific schema, all user tables across the entire database, or by explicitly specifying a set of target tables. After determining the set of target tables, the system can obtain the structural information of each table, including column names, number of columns, data types, nullability, default values, and index structure, by querying the system directory (such as the pg_class, pg_attribute, and pg_index metadata tables in PostgreSQL). This structured metadata provides basic support for the subsequent generation of scan operator nodes and provides data attribute constraints for the generation of subsequent upper-level operators such as joins and filters.

[0105] When a database introduces new execution operators or query syntax, the generator can be configured to generate more nodes related to the new operator. When verifying the compatibility and stability of new functions across different operators, the generation probability of related function operations can be increased.

[0106] 3. Generating SQL queries

[0107] Once the query plan tree is generated, it is then transformed into a valid SQL query. Each operator corresponds to a part of the SQL query, and the generated SQL query includes appropriate keywords such as SELECT, FROM, WHERE, JOIN, and GROUP BY; the generation follows a top-down approach.

[0108] The query generation rules are as follows:

[0109] Scan operator: corresponds to the table following "from";

[0110] Filtering operators: Corresponding to the WHERE clause, they filter data;

[0111] Join operators: Generate join statements based on the join type (such as INNER JOIN, LEFT JOIN, etc.). Figure 2 As shown, the join can generate (... from t2 join t3 on t2.c6 = t3.c11, or generate from t2, t3where t2.c6 = t3.c11. To generate test cases that cover as much code as possible, both are generated).

[0112] Aggregate operators: generate corresponding GROUP BY clauses and aggregate functions, such as `select SUM(t1.c1) from …group by t1.c2`.

[0113] Sort operator: generates ORDER BY clause;

[0114] Limit operator: generates a limit clause;

[0115] Common expression: generates with r1 as (...), where the parentheses can contain SQL generated by another complete query plan tree;

[0116] For example, we now have tables t1(c1, c2, c3, c4, c5), t2(c6, c7, c8, c9, c10), and t3(c11, c12, c13, c14, c15).

[0117] First, a left join is selected for the left table. The left table is joined using scan operator t1, and a filter condition is randomly generated for t1. A join 2.inner join is selected for the right table. Since the column attributes returned by join 2 are currently uncertain, the join condition will be randomly selected after the right join tree is finalized. Join 2 selects an index scan t2 and a sequential scan t3. Before executing the generated SQL, it is necessary to ensure that an index exists on column t2.c8. At this point, the result of join 2 is determined. Join 1 can randomly generate a join condition, such as t1.c1 = r2.c6 (where r2 represents the result of join 2). The output of join 1 can then be randomly selected from the left table t1 and the right table r2, such as (t1.c1, t1.c4, r2.c8, r2.c14). The generated plan tree now contains all the results of join 1. A sorting operator is added above the join 1 node, sorted according to t1.c2, resulting in the following... Figure 2 The plan tree shown.

[0118] Figure 2 The sorting operator can generate `order by t1.c1`, and the concatenation operator generates the content after `from`, according to... Figure 2 This can generate `from t1 left join (...) r2 on t1.c1 = r2.c6`, where the content of `r2` corresponds to `t2 innerjoin t3 on t2.c6 = t3.c11`. The filtering conditions of the scan operator correspond to the content after the `where` clause in the SQL statement. Figure 2 This can generate `where t1.c1>10 and t2.c3>-1 and t3.c3>-1`. The content after `SELECT` can be the output of the sorting operator, which would be `SELECT t1.c1, t1.c4, r2.c8, r2.c14`.

[0119] Concatenating the above generated content, we get: select t1.c1,t1.c4, r2.c8, r2.c14 from t1left join (t2 inner join t3 on t2.c6 = t3.c11) r2 on t1.c1 = r2.c6 wheret1.c1>10 and t2.c3>-1 and t3.c3>-1 order by t1.c1.

[0120] Since t2 uses an index scan, an index needs to be created on column c6 for t2.

[0121] 4. Testing Process

[0122] 1) Information extraction stage

[0123] Extract the metadata information required to generate SQL from the target database, including but not limited to: table definitions (table name, column name, data type, constraints, etc.), data type definitions, operator definitions (including overload information, input and output types), built-in and user-defined function information, aggregate functions and their supported input types, supported implicit / explicit type conversion rules, etc.

[0124] 2) Test configuration loading phase

[0125] The functional modules of the database under test (such as specific type support, function behavior, executor stability, etc.);

[0126] The target of a specific operator (such as a join operator or an aggregation operator);

[0127] Maximum depth of the query plan tree;

[0128] Special strategies (such as whether to force the use of certain types of operators or functions); this information is used to guide the SQL generation strategy.

[0129] 3) Obtain the objectives and constraints of the current test task, including:

[0130] The construction of test data is not part of the core content of this method, but it should meet the data source requirements: it should cover common types, boundary values, null values, typical distributions and multiple data volumes to ensure that the generated queries have good coverage and robustness.

[0131] 4) SQL construction phase

[0132] Following the algorithm and process described in this method, generate random test SQL that meets the input constraints. During the SQL construction process, it is necessary to ensure semantic correctness (such as type matching, operator input parameters meeting requirements, etc.) and structural diversity (such as multiple join combinations, nested subqueries, etc.).

[0133] 5) Execution and Behavior Verification Phase

[0134] Connect to the target database using a client, execute the generated test SQL statements one by one, and monitor the behavior during the execution process, including but not limited to:

[0135] Whether the execution was successful (no syntax / semantic errors);

[0136] Does it trigger a system crash (such as a core dump, PANIC, etc.)?

[0137] Check for abnormal behaviors such as hanging, deadlock, and OOM.

[0138] Check if ERROR / ASSERT / FATAL messages appear in the runtime logs. Log analysis and system status monitoring can help assess database behavior.

[0139] 6) Results Recording and Archiving Stage

[0140] For each test SQL statement, record the following key information:

[0141] Original SQL content;

[0142] Execution result (success, failure, exception type);

[0143] Execution time, resource consumption, etc.;

[0144] Does it trigger an error / crash, etc.?

[0145] The target being tested (e.g., whether a specific operator or function is hit);

[0146] All information should be stored in a structured manner to facilitate subsequent reproduction, regression, attribution analysis, and statistical coverage.

[0147] The method of the present invention is applicable to the following scenarios:

[0148] Database kernel testing: Generate diverse query plans before and after database updates to test the impact of database updates on performance, correctness, and stability.

[0149] Performance regression testing: By generating random query plans, the performance of the database under different query loads is evaluated.

[0150] Database optimizer testing: Evaluate the performance and correctness of the query optimizer by comparing different execution plans.

[0151] Automated testing tools: The method of this invention can be integrated into automated testing tools to achieve fully automated testing.

[0152] The technical advantages of this method include at least one of the following:

[0153] Improve test coverage: Generate query plan trees based on operator combinations, which can cover multiple execution paths of the database optimizer and execution engine, thereby improving test coverage.

[0154] Automated SQL query generation: SQL queries are generated through algorithms, reducing manual intervention and improving testing efficiency.

[0155] Flexible test generation: It can generate diverse queries based on the operators supported by the database, adapting to complex database kernel testing needs.

[0156] Impact analysis of changes: By analyzing the execution plans of different versions of the database, the impact of database updates on performance and stability can be quantified.

[0157] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for generating SQL based on operator combination for database kernel testing, characterized in that the steps include... include: S1, extract metadata from the target database and build an operator library with defined input and output structures; Metadata is obtained by querying the system directory of the target database, which includes table structure information; The metadata includes data table definitions, data type definitions, operator definitions, function definitions, and type conversion rules. The metadata is used to ensure type compatibility during the query plan tree generation and SQL query generation processes. S2, retrieve test configuration and generate test constraints. The test configuration includes: The functional modules of the database under test, the coverage targets of specific operators, the maximum depth of the query plan tree, and special strategies; The test constraints include at least one of the following: limiting specific operators to be included in the query plan tree, limiting the minimum or maximum number of tables accessed in the database, limiting access to specific tables, limiting the data types included in the output results, limiting the number of specific operators to a threshold, and limiting the depth threshold of the query plan tree. S3, based on the operator library and the aforementioned metadata, generates a query plan tree recursively. Each node in the query plan tree is an operator, and the edges between nodes represent the dependencies between operators. The generated query plan tree satisfies the test constraints. Query plan tree generation in S3 includes: Based on the testing requirements, select an operator from the operator library as the current node of the query plan tree, prioritizing scan operators, join operators, filter operators, or common expression operators; Based on the input requirements of the current node, select the matching sub-operator and recursively generate one or more child nodes for it until the preset termination condition is reached, wherein the output structure of the child node matches the input structure required by the operator of the current node as the query plan tree. Recursively construct subtrees until the depth of the query plan tree is reached, according to the preset threshold. After the child nodes of the current node are generated, the output column attributes of the current node are determined based on the output column information traced back from the child nodes, and the conditions or operations to be executed by the operator of the current node as the query plan tree are generated. The output columns are all columns of the lower subtree or randomly selected columns, and ambiguity is eliminated by aliases; The scan operator supports at least one of the following: basic table scan, materialized view scan, subquery scan, function return table scan, and outer table scan; S3 also includes adding aggregation operators, sorting operators, and restriction operators to the query plan tree; After the aggregation operator is generated, sorting operators and restriction operators can be further added to form a variety of combinations; It also includes performing function operations or type conversions on the output columns of the query plan tree, wherein the function operations are based on function definitions in the metadata, and the type conversions are based on type conversion rules in the metadata; S4. Generate an SQL query from top to bottom based on the metadata and the query plan tree; S5, Execute the SQL query on the target database, monitor the behavior during the execution process, and generate the execution results of the database test. The execution results include the execution status, exception information, execution time, and resource consumption. The monitoring content includes at least one of the following situations: syntax or semantic errors, system crashes, execution suspension, deadlocks, memory overflows, and error messages in the logs; S6, record the SQL query and execution results, and generate a structured test result dataset for subsequent reproduction, regression testing and coverage analysis; The test result dataset includes the following information: original SQL content, execution result, execution time, resource consumption, triggered error type, and hit test target.

2. The SQL generation method based on operator combination for database kernel testing according to claim 1, characterized in that, The operator library includes scanning operators, filtering operators, connection operators, aggregation operators, sorting operators, restriction operators, and common expression operators; Scan operators scan data in a table and output rows; filter operators filter data based on specific conditions and output rows that meet the conditions; join operators join two result sets and output randomly selected columns; aggregation operators perform aggregation operations on the input result set and output a single result or a result set; sort operators sort the input result set and output the sorted result set; limit operators limit the number of output results; common expression operators generate named temporary result sets.

3. The SQL generation method based on operator combination for database kernel testing according to claim 1, characterized in that, SQL queries in S4 include the SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, and LIMIT clauses; SQL query generation includes: Map the scan operators in the query plan tree to FROM clauses; Map the filter operator to a WHERE clause; Map the join operator to a JOIN statement or a WHERE condition; Map aggregation operators to GROUP BY clauses and aggregation functions; Map sorting operators to ORDER BY clauses; Map the restriction operator to a LIMIT clause; Map public expression operators to WITH clauses.

4. The SQL generation method based on operator combination for database kernel testing according to claim 1, characterized in that, It also includes the following steps: Application scenarios include at least one of the following: database kernel testing, performance regression testing, database optimizer testing, and integration with automated testing tools.

5. The SQL generation method based on operator combination for database kernel testing according to claim 1, characterized in that, The operator library supports expansion. When the target database introduces new operators or query syntax, the generation probability of the corresponding operators is increased to verify the compatibility and stability of the new operators. The query plan tree can be embedded into other query plan trees as subqueries or common expressions to form a nested query structure; The SQL generation method is applicable to a variety of relational databases, including PostgreSQL, MySQL, openGauss, and Oracle, and adapts to the characteristics of different databases through the metadata.

Images