Database connection operation optimization method, storage medium and computer device

Abstract

The application provides a database connection operation optimization method, a storage medium and a computer device. The method comprises the following steps: starting optimization of a connection operation by an optimizer; judging whether two side sub-tables participating in the connection operation satisfy a preset optimization condition; if yes, creating an alternative plan according to a preset connection order and a connection mode; and adding the alternative plan into an execution plan alternative queue, and selecting an actual execution plan from the execution plan alternative queue by the optimizer. According to the scheme, the execution efficiency of the connection operation is improved by targeted optimization, the execution complexity of the connection query is reduced, and the execution time of the connection operation is saved.

Description

Technical Field

[0001] This invention relates to database technology, and in particular to an optimization method for database connection operations, a storage medium, and a computer device. Background Technology

[0002] Join queries are the most common type of query in relational databases. Joins are a key characteristic of the relational database model and a distinguishing feature from other types of database systems.

[0003] Database joins between multiple tables typically employ a cost-based approach to select the join order and method. The accuracy of this cost-based selection depends on data sampling and the cost calculation algorithm. Commonly used join algorithms in existing database products include nested loops, hash joins, and merge sort joins. To improve join efficiency, database executors also utilize techniques such as bitmap filters to assist in the execution of these join algorithms.

[0004] However, the aforementioned join algorithms still have room for further optimization. For example, in scenarios involving a small table T (a table with very little data, or a node resulting from a subquery or a join of multiple tables with a small data volume) and a complex subquery Q, the total SQL execution time is significantly affected by the complex subquery Q, as the complex subquery is a time-consuming operation. When the complex subquery has a large data volume and a long execution time, the total query execution time is greatly affected by the complex subquery Q. Existing join algorithms generally select execution plans with low efficiency, leading to a decrease in overall execution efficiency. Summary of the Invention

[0005] One object of the present invention is to provide an optimized method, storage medium, and computer device for database connection operations that at least solves any of the above-mentioned technical problems.

[0006] A further objective of this invention is to save the execution time of connection operations.

[0007] Another further objective of this invention is to specifically improve efficiency for connection operation scenarios.

[0008] Specifically, the present invention provides an optimization method for database connection operations, comprising:

[0009] The optimizer initiates optimization of the connection operation;

[0010] Determine whether the two sub-tables involved in the join operation meet the preset optimization conditions;

[0011] If so, create alternative plans according to the preset connection order and connection method;

[0012] The alternative plans are added to the execution plan candidate queue, and the optimizer selects the actual execution plan from the execution plan candidate queue.

[0013] Optionally, the two sub-tables include a first sub-table and a second sub-table, and the optimization conditions include: the estimated number of rows returned by the first sub-table is less than a preset cardinality estimation threshold, and the second sub-table contains a subquery and the estimated execution cost is greater than a preset execution cost threshold.

[0014] Optionally, the step of the optimizer selecting an actual execution plan from the queue of execution plan candidates includes:

[0015] Calculate the connection cost for each execution plan in the candidate queue, and select the one with the lowest connection cost as the actual execution plan.

[0016] Alternatively, the connection cost of the created alternative plan is the sum of the following costs:

[0017] The cost of scanning the first sub-table;

[0018] The cost of materializing and caching the data returned from the scan of the first sub-table;

[0019] The cost of adding the data returned from the scan of the first sub-table as a filter condition for the subquery of the second sub-table before executing the subquery;

[0020] The execution cost of using the data returned by the subquery of the second sub-table as the outer table and the scan data returned by the cached first sub-table as the inner table for a nested loop join is calculated.

[0021] Optionally, after the step of optimizing the connection operation initiated by the optimizer, the following may also be included:

[0022] The join operations are enumerated using the join algorithms supported by the optimizer to obtain the execution plan corresponding to each join algorithm, thus forming a queue of execution plan candidates.

[0023] Optionally, the optimizer supports one or more of the following join algorithms: nested loop algorithm, hash join algorithm, and sort-merge join algorithm.

[0024] Optionally, after the step of the optimizer selecting an actual execution plan from the queue of execution plan candidates, the following may also be included:

[0025] The actual execution plan is executed by the database executor.

[0026] Optionally, if either of the two sub-tables involved in the join operation does not meet the optimization conditions, the process further includes: the optimizer selecting an actual execution plan from the enumerated candidate queue.

[0027] According to another aspect of the present invention, a machine-readable storage medium is also provided, on which a machine-executable program is stored, wherein the machine-executable program, when executed by a processor, implements an optimized method for any of the above-described database connection operations.

[0028] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a machine-executable program stored in the memory and running on the processor, and an optimized method for implementing any of the above-described database connection operations when the processor executes the machine-executable program.

[0029] The database connection operation optimization method of the present invention analyzes the usage scenarios of connection operations, creates optimization strategies for connection operations that meet preset optimization conditions, and creates alternative plans according to preset connection order and connection method as alternatives for the optimizer to select execution plans. By optimizing in a targeted manner, the execution efficiency of connection operations is improved, the execution complexity of connection queries can be reduced, and the execution time of connection operations can be saved.

[0030] Furthermore, in the database connection operation optimization method of the present invention, the optimization conditions can be that the estimated number of rows returned by the first sub-table is less than a preset cardinality estimation threshold, and the second sub-table contains a subquery and its estimated execution cost is greater than a preset execution cost threshold. The return result of the first sub-table is used as a constant parameter to replace the connection conditions of the two tables, and the connection conditions are passed into the subquery as filtering conditions to reduce the complexity of the subquery, thereby improving execution efficiency.

[0031] Furthermore, the database connection operation optimization method of the present invention greatly improves the execution efficiency of connection operations by reducing the number of records involved in the calculation in complex queries.

[0032] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0033] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings:

[0034] Figure 1 This is a schematic diagram of an optimization method for database connection operations according to an embodiment of the present invention;

[0035] Figure 2 This is a flowchart of the optimizer's workflow in a database connection operation optimization method according to an embodiment of the present invention;

[0036] Figure 3 This is a schematic diagram of the execution plan data structure generated by a database connection operation optimization method according to an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram of the execution process in an optimization method for database connection operations according to an embodiment of the present invention;

[0038] Figure 5 This is a flowchart illustrating the sub-table optimization process in a database connection operation optimization method according to an embodiment of the present invention.

[0039] Figure 6 This is a schematic diagram of a machine-readable storage medium according to an embodiment of the present invention; and

[0040] Figure 7 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0041] For multi-table joins, the database optimizer selects different join algorithms based on different use cases. This embodiment's method addresses a use case where a small table T is joined with a complex subquery Q. The small table is a table with a very small amount of data; it could refer to a node with a very small amount of data after filtering, such as a table with a very small number of records, or it could be the result of a subquery or a join of multiple tables. Since the complex subquery is a time-consuming operation, the total SQL join operation execution time is significantly affected by the complex subquery Q.

[0042] The implementation principle of this embodiment is as follows: an alternative execution plan is created, which uses the execution result of the smaller table as a constant parameter to replace the join condition of the two tables, and uses the join condition as a filter condition to pass into the complex subquery, thereby reducing the complexity of the complex subquery and improving the execution time of the subquery.

[0043] Let's take an SQL (Structured Query Language) statement as an example: select * from a where exists(select *(select * from b union select * from c)v where v.id = a.id).

[0044] For a specific test database, scanning table A returns only 8 rows with v.id = a.id, while scanning tables B and C returns 2 million rows. Most of the SQL execution time is spent on merging (APPEND) and deduplicating (HashAggregate) these 2 million rows. If we first retrieve a.id from the join condition v.id = a.id, then convert it into the value of the id column from these 8 rows, and then pass the id column values ​​from these 8 rows to a subquery and finally push it down to b.id in(8 id values ​​from a) and c.id in(8 id values ​​from a), then the number of records scanned from tables B and C will be much smaller.

[0045] In reality, the query that ultimately satisfies the condition `select * from B where id in(select * from A) union select * from C where id in(select * from A)` returns only one row.

[0046] The database connection operation optimization method in this embodiment optimizes the connection algorithm at the database optimizer level. A new connection algorithm is generated when producing an execution plan for an SQL query statement that joins two tables.

[0047] Figure 1 This is a schematic diagram of a method for optimizing database connection operations according to an embodiment of the present invention. The method for optimizing database connection operations generally includes:

[0048] Step S102: The optimizer initiates optimization of the connection operation;

[0049] Step S104: Determine whether the two sub-tables involved in the join operation meet the preset optimization conditions;

[0050] Step S106: If the above preset optimization conditions are met, create alternative plans according to the preset connection order and connection method;

[0051] Step S108: Add the alternative plans to the execution plan alternative queue, and the optimizer selects the actual execution plan from the execution plan alternative queue.

[0052] The two sub-tables involved in the join operation can be denoted as the first sub-table (small table T) and the second sub-table (complex subquery Q). The optimization conditions include: the estimated number of rows returned by the first sub-table is less than the preset cardinality estimation threshold, and the second sub-table contains a subquery and the estimated execution cost is greater than the preset execution cost threshold.

[0053] The specific join process for creating an alternative plan can be as follows: First, execute the query on the smaller table, cache the query results, then transform the join conditions into query conditions on the larger table to filter the larger table, and finally join the query results of the larger table with the cached query results of the smaller table.

[0054] Step S108 involves the optimizer selecting an actual execution plan from the execution plan candidate queue. This selection can be based on the execution cost of all execution plans in the queue. For example, the connection cost of each execution plan in the candidate queue can be calculated, and the plan with the lowest connection cost can be selected as the actual execution plan. The selected actual execution plan is then executed by the database executor.

[0055] The connection cost of the created alternative plans is the sum of the following costs:

[0056] (1) Cost of scanning the first sub-table;

[0057] (2) The cost of materializing and caching the data returned from the scan of the first sub-table;

[0058] (3) The cost of executing the subquery after adding the scan return data of the first subtable as the filter condition of the subquery of the second subtable;

[0059] (4) The execution cost of using the returned data of the subquery of the second sub-table as the outer table and the scan returned data of the cached first sub-table as the inner table for a nested loop join.

[0060] In addition to the candidate plans created above, the aforementioned candidate queue may also include other execution plans formulated by the optimizer based on other algorithms. That is, after the optimizer initiates the optimization of the join operations, the process may further include: enumerating the join operations using join algorithms supported by the optimizer to obtain the execution plan corresponding to each join algorithm, thereby forming the execution plan candidate queue. The join algorithms supported by the optimizer may include any one or more of the following: nested loop algorithms, hash join algorithms, and sort-merge join algorithms. Those skilled in the art can choose the algorithm for generating the execution plan candidate queue as needed. Since the nested loop algorithms, hash join algorithms, and sort-merge join algorithms listed above are themselves well-known to those skilled in the art, they will not be elaborated upon here.

[0061] If the result of step S104 is that either of the two sub-tables involved in the connection operation does not meet the optimization conditions, in this case, the optimizer can select an actual execution plan from the candidate queue obtained by enumeration.

[0062] Figure 2It is the flowchart of the optimizer in the optimization method of database connection operation according to an embodiment of the present invention. Taking the database executing join A and B as an example, the physical optimization module of the optimizer will first perform cardinality estimation and cost estimation for the two sub-tables (table A and table B) participating in the join, enumerate the supported join algorithms (including nested loop algorithm, hash join, sort-merge join, etc.) based on these estimated data, calculate the execution cost of each join algorithm, and finally select the algorithm with the optimal cost. One of the main improvements in this embodiment is that when the optimizer enumerates the join algorithms, if the two tables participating in the join meet the following conditions, the improved join algorithm provided in this embodiment is added when enumerating the join algorithms. The optimizer of the database can execute the following steps:

[0063] Step S202, enter the optimizer and start optimizing the join operation.

[0064] Step S204, determine whether the two sub-tables on both sides of the join operation meet the preset optimization conditions; the optimization conditions require that the estimated number of returned rows of sub-table A is less than the cardinality estimation threshold row_threshold; and sub-table B is a sub-query, and the estimated execution cost is greater than the execution cost threshold cost_threshold.

[0065] When the cardinality estimation threshold row_threshold is set to 10 and the execution cost threshold cost_threshold is set to 1, if it occurs that for table A, its estimated number of rows row = 8 < row_threshold; and for the sub-query, its estimated cost cost = 7 > cost_threshold; then it is considered to meet the above optimization conditions.

[0066] Step S206, create a join plan (named FilterJoinPath) and calculate its execution cost. The execution cost includes the sum of the following costs:

[0067] (1) The cost of scanning table A

[0068] ((2) The cost of materializing the data returned by table A and establishing a cache. The cost of this step is an additional cost compared to the existing join algorithms, and the cost of this step can be recorded as cost X.

[0069] (3) Push the returned data in A as a filter condition to sub-query B, and then calculate the execution cost of B. Because an additional filter condition is introduced, most records will be filtered out in the simple table scan of B, resulting in an improvement in the query efficiency of B. The saved execution cost is recorded as Y. Then when Y is greater than X, the method of this embodiment will greatly improve the execution efficiency of the SQL join operation, and as the degree of Y being greater than X increases, the execution efficiency will gradually increase.

[0070] (4) The execution cost of using the returned data of B as the outer table and the cached data of A as the inner table for a nested loop join.

[0071] Step S208: FilterJoinPath is added to the candidate queue, and its execution cost is compared with other plans to select the execution plan with the lowest cost. The pseudocode for this step is:

[0072] add_path(joinrel,create_nestloop_path(a,b)); / Adds an execution plan for a nested loop algorithm;

[0073] add_path(joinrel,create_hashjoin_path(a,b)); / Adds an execution plan for the hash join algorithm;

[0074] add_path(joinrel,create_mergejoin_path(a,b)); / Adds the sort-merge-join algorithm execution plan;

[0075] add_path(joinrel,create_filterjoin_path(a,b)); / Add the connection algorithm provided by the method in this embodiment;

[0076] `set_cheapest(joinrel)`: Selects the optimal algorithm from the four join algorithms above as the final execution plan.

[0077] Step S210: Enter the actuator.

[0078] When the optimizer selects the candidate queue provided in this embodiment as the final connection algorithm based on the cost, a final execution plan data structure is generated. Figure 3 This is a schematic diagram of the execution plan data structure generated by the database join operation optimization method according to an embodiment of the present invention. Taking `select * from a where exists(select *(select * from b union select * from c)v where v.id = a.id` as an example, the main variables used are identified. The join plan has two child nodes: the left node is the execution plan of subquery v, and the right node is the execution plan of table A (assuming a full table scan SeqScan). The execution plan of subquery v is a merge operation (APPEND), and its child nodes are scans of tables B and C. The join condition is pushed down to the filtering conditions for tables B and C, and the join condition is added to the execution plans of tables B and C.

[0079] Figure 4 This is a schematic diagram illustrating the execution process of an optimization method for database connection operations according to an embodiment of the present invention. Figure 5 This is a schematic flowchart illustrating the sub-table optimization process in a database connection operation optimization method according to an embodiment of the present invention. The execution process of the executor includes:

[0080] Step S402: The executor begins executing the execution plan;

[0081] Step S404: Whether this is the first execution can be determined by judging the execution flag start of FilterJoin. If start = true, that is, when the execution flag indicates the start state, it is determined that the executor starts to execute the actual execution plan.

[0082] Step S406: If this is the first execution, scan each record of the smaller table A sequentially, apply the filtering conditions, and cache the results; that is, the executor first loops through and executes the scan execution plan filterjoin->righttree for the smaller table A. Each execution returns one record. For each record, first store the returned record in list X.

[0083] Step S408: Store the values ​​from the columns related to the join condition in table A in a list in memory; for example, the ID column number stored in the execution plan filterjoin->innercols list based on the join condition A.id = V.id is used to push the ID column value of that record down to the lower level of the sub-plan filterjoin->lefttree in the form "id = value" for the scan operations of B and C. This process is repeated until all records in A are returned, then start = false, i.e., the execution flag is changed to the in progress state. The execution status is indicated by setting the execution flag start.

[0084] Step S410: Execute the execution plan of subquery B to obtain the filtered records;

[0085] Step S420: Join the records obtained from subquery B according to the join conditions and each data in cached table A. If the join completion condition is met, return the join result.

[0086] The execution process of step S410 is as follows: Figure 5 As shown, it may include:

[0087] Step S412: Begin executing the execution plan for subquery V;

[0088] Step S414: Read records one by one from the data table participating in the subquery of the second sub-table;

[0089] Step S416: Filter the read records. If the column of the data table involves a join condition, replace the column name of table A in the join condition with the value of that column in cache A, and determine whether the read record meets the condition. If not, read the next record of the table and continue to judge.

[0090] In step S418, after all records read from each data table satisfy the join condition, these records are used for other subquery operations. The execution plan is an append merge, which first reads records from table B, then reads records from table C, and finally merges the two. Other operations can still follow the original logic.

[0091] When reading each record from table B or table C, in addition to the original filtering conditions, several additional filtering conditions introduced in the first step are added. These filtering conditions will reduce the number of records returned by scanning tables B and C, thereby further reducing the number of records involved in the append operation.

[0092] In other words, the above execution process can be as follows: scan the data of the first sub-table, obtain the data returned by the scan, and obtain the first result set (that is, the set of records returned by the scan of the small table A); save the values ​​in the columns related to the join operation in the first sub-table as supplementary filtering conditions; use the supplementary filtering conditions to filter the data tables participating in the subquery of the second sub-table, and use the filtered data (that is, the records after replacing the column names of table A in the join conditions with the values ​​of that column in cached A) to perform the subquery and obtain the second result set; join the second result set and the second result set to obtain the join result.

[0093] When the above join is executed, the query on the smaller table is executed first, and the query results are cached. Then, the join conditions are transformed into query conditions on the larger table to filter the larger table. Finally, the query results of the larger table and the cached query results of the smaller table are joined. This reduces the number of records involved in the calculation in complex queries, thereby greatly improving the execution efficiency of SQL and reducing the execution time of SQL queries.

[0094] This embodiment also provides a machine-readable storage medium and a computer device. Figure 6 This is a schematic diagram of a machine-readable storage medium 60 according to an embodiment of the present invention. Figure 7 This is a schematic diagram of a computer device 70 according to an embodiment of the present invention.

[0095] The machine-readable storage medium 60 stores a machine-executable program 61 thereon, which, when executed by a processor, implements the optimized method for database connection operations of any of the above embodiments.

[0096] Computer device 70 may include memory 720, processor 710, and machine-executable program 61 stored on memory 720 and running on processor 710, and processor 710 executes machine-executable program 61 to implement the optimized method for database connection operation of any of the above embodiments.

[0097] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any machine-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-based system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0098] For the purposes of this embodiment, the machine-readable storage medium 60 can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection (electronic device) having one or more wires, a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, the computer-readable medium 40 can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0099] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0100] Computer device 70 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 70 can be a cloud computing node. Computer device 70 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 70 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0101] Computer device 70 may include a processor 710 adapted to execute stored instructions and a memory 720 that provides temporary storage space for the operation of said instructions during operation. The processor 710 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 720 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0102] The processor 710 can be connected via a system interconnect (e.g., PCI, PCI-Express, etc.) to an I / O interface (input / output interface) suitable for connecting the computer device 70 to one or more I / O devices (input / output devices). I / O devices may include, for example, a keyboard and indicating devices, where indicating devices may include a touchpad or touchscreen, etc. I / O devices may be built into the computer device 70 or may be external devices connected to the computing device.

[0103] The processor 710 can also be linked via a system interconnect to a display interface suitable for connecting the computer device 70 to a display device. The display device may include a display screen that is a built-in component of the computer device 70. The display device may also include an external computer monitor, television, or projector connected to the computer device 70. Furthermore, a network interface controller (NIC) may be adapted to connect the computer device 70 to a network via a system interconnect. In some embodiments, the NIC may use any suitable interface or protocol (such as an Internet Minicomputer System Interface) to transmit data. The network may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. Remote devices can connect to the computing device via the network.

[0104] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

[0105] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. An optimization method for database connection operations, comprising: The optimizer initiates optimization of the connection operation; Determine whether the two sub-tables involved in the connection operation meet the preset optimization conditions; If so, create alternative plans according to the preset connection order and connection method; The alternative plans are added to the execution plan candidate queue, and the optimizer selects the actual execution plan from the execution plan candidate queue; The two sub-tables include a first sub-table and a second sub-table, and The optimization conditions include: the estimated number of rows returned by the first sub-table is less than a preset cardinality estimation threshold, and the second sub-table contains a subquery and the estimated execution cost is greater than a preset execution cost threshold. The step of the optimizer selecting an actual execution plan from the queue of execution plan candidates includes: Calculate the connection cost for each execution plan in the candidate queue, and select the one with the lowest connection cost as the actual execution plan.

2. The method of optimizing database connection operations of claim 1, wherein, The connection cost of the created alternative plan is the sum of the following costs: The cost of scanning the first sub-table; The cost of materializing and caching the scanned data from the first sub-table; The cost of executing the subquery after adding the scan return data of the first subtable as a filter condition of the subquery of the second subtable; The execution cost of performing a nested loop join is calculated by using the returned data of the subquery of the second sub-table as the outer table and the cached scan returned data of the first sub-table as the inner table.

3. The method of optimizing database connection operations of claim 1, wherein, Following the step where the optimizer initiates the optimization of the connection operation, the following is also included: The join operation is enumerated using the join algorithms supported by the optimizer to obtain the execution plan corresponding to each join algorithm, thereby forming the queue of execution plan candidates.

4. The method of optimizing database connection operations of claim 3, wherein, The optimizer supports one or more of the following join algorithms: nested loop algorithm, hash join algorithm, and sort-merge join algorithm.

5. The method of optimizing database join operations of claim 1, wherein, Following the step of the optimizer selecting an actual execution plan from the queue of execution plan candidates, the method further includes: The actual execution plan is executed by the executor of the database.

6. The method of optimizing database connection operations of claim 1, wherein, If either of the two sub-tables involved in the join operation does not satisfy the optimization condition, the method further includes: The optimizer selects an actual execution plan from the enumerated candidate queue.

7. A machine-readable storage medium having a machine-executable program stored thereon, the machine-executable program, when executed by a processor, implementing the optimized method for database connection operations according to any one of claims 1 to 6.

8. A computer device comprising a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor, when executing the machine-executable program, implements an optimized method for database connection operations according to any one of claims 1 to 6.

Images