A data-driven based like predicate selection rate estimation method and system
By constructing a trie and a data-driven model, the LIKE predicate is transformed into a range predicate. Combined with a cardinality estimation result library and a Least Recently Used strategy, the accuracy and efficiency issues of LIKE predicate cardinality estimation are solved, achieving fast and accurate cardinality estimation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANDONG UNIV
- Filing Date
- 2024-01-12
- Publication Date
- 2026-06-09
AI Technical Summary
Existing technologies suffer from insufficient cardinality estimation accuracy and high cost when processing SQL queries containing LIKE predicates, making it difficult to balance the time and accuracy issues caused by sampling.
By constructing a trie to transform the like predicate into a range predicate of numeric type, and using a data-driven model for cardinality estimation, combined with a cardinality estimation result library and a least recently used strategy, fast cardinality estimation is achieved.
It achieves fast and accurate cardinality estimation of like predicates, reduces time costs and improves estimation accuracy, and avoids the accuracy loss of traditional methods.
Smart Images

Figure CN117785916B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of query selectivity prediction technology for relational databases, and in particular to a data-driven method and system for estimating selectivity using the like predicate. Background Technology
[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.
[0003] Query optimization is a core component of database management systems, involving the construction of the database query execution plan tree, the selection of specific implementation methods at the plan tree nodes, parameter selection, and compilation / execution choices. The query optimizer mainly consists of three components: cardinality estimation, cost model, and plan enumeration. Among these three, cardinality estimation is the bottleneck of the entire database query optimization process; in other words, the cardinality estimation problem (i.e., the selection rate estimation problem) is the most challenging query optimization problem. In most SQL query scenarios, the cardinality estimation component relies on traditional database statistics. These statistics mainly include histograms reflecting data distribution and maximum frequency values (MCVs) reflecting the frequency of extreme data. However, when the SQL query contains a `LIKE` predicate, traditional statistics such as histograms and MCVs become ineffective. Therefore, cardinality estimation will be performed without any auxiliary information. Thus, cardinality estimation with `LIKE` predicates is extremely difficult.
[0004] Currently, most mainstream databases rely on a "magic constant" to solve the cardinality estimation problem for SQL queries containing LIKE predicates. According to the open-source code of PostgreSQL, the "magic constant" used by PostgreSQL is 1 / 3. Specifically, when the PostgreSQL query optimizer processes an SQL query containing a LIKE predicate, the cardinality estimation component directly sets the selectivity estimate to 0.333. This is obviously a very convenient approach, but it sacrifices accuracy. The optimizer ignores the actual distribution of the data and directly assumes that one-third of the data meets the LIKE predicate condition, which is clearly unreasonable. To compensate, advanced databases, represented by Oracle, use sampling methods to estimate cardinality as accurately as possible. However, sampling methods have inherent problems, namely, the difficulty in balancing the costs and benefits of sampling. Large-scale sampling can certainly provide a more accurate understanding of the data distribution and make more accurate estimates, thus increasing the chance of choosing a faster and more efficient execution plan. However, large-scale sampling itself leads to higher time costs, essentially using a more time-consuming method to save time, which is unwise. Furthermore, when dealing with SQL queries containing joins, the sampling method also encounters the "zero tuple problem".
[0005] In summary, how to achieve low-cost and high-efficiency cardinality estimation of like predicates has become a technical problem that needs to be solved by existing technologies. Summary of the Invention
[0006] To address the shortcomings of existing technologies, the purpose of this invention is to provide a data-driven method and system for estimating the selectivity of like predicates. This method can convert like predicates into numeric range predicates, which are then used by a data-driven model for cardinality prediction. The storage mechanism is used to accelerate this process.
[0007] To achieve the above objectives, the present invention is implemented through the following technical solution:
[0008] The first aspect of this invention provides a data-driven method for estimating the selectivity of like predicates, comprising the following steps:
[0009] Receive query statements containing the LIKE predicate and determine the type of the LIKE predicate;
[0010] Construct a trie, find the corresponding trie based on the type of the like predicate, and convert the like predicate query into a range predicate query of numeric type;
[0011] Based on the range predicate query of the numeric type, a similarity query is performed in the cardinality estimation result database. If there are similarity query results exceeding the set threshold, the cardinality estimation results obtained are directly reused; if there are no similarity query results exceeding the set threshold, cardinality estimation is performed using a data-driven model.
[0012] Furthermore, the types of like predicates include prefix-type like predicates, suffix-type like predicates, and substring-type like predicates.
[0013] Furthermore, the specific steps for constructing a trie are as follows:
[0014] Starting from the root node, determine the number of branches in the first level based on the number of different first letters in all attribute values; then determine the branch nodes in the next level of the trie based on the second letter of each word, and so on, to complete the construction of the trie; after the trie is constructed, encode the words into ranges.
[0015] Furthermore, the data-driven model is constructed using an autoregressive model, and cardinality estimation is performed by outputting the probability distribution.
[0016] Furthermore, the similarity between two query statements is measured by calculating the lengths of the intersection and union of the range intervals and then calculating the ratio.
[0017] Furthermore, if there are no similarity query results exceeding the set threshold, the cardinality estimation result library is updated based on the cardinality estimation result.
[0018] Furthermore, the cardinality estimation result library is updated using a least recently used strategy: if a new query enters, after scanning, if the system finds the first query with a similarity exceeding the threshold, it will mark the first query with a similarity exceeding the threshold; if a new query enters, after scanning, if no query in the cardinality estimation result library has a similarity exceeding the threshold with the new query, the system will scan the markings of each query in the result library, remove the least recently used query, replace it with the new query, and after the data-driven model provides the cardinality estimation result for the new query, the result will be written into the cardinality estimation result library, completing one update.
[0019] A second aspect of the present invention provides a data-driven like predicate selection rate estimation system, comprising:
[0020] The statement retrieval module is configured to receive query statements containing the like predicate and determine the type of the like predicate;
[0021] The format conversion module is configured to build a trie and find the corresponding trie based on the type of the like predicate to convert like predicate queries into range predicate queries of numeric type.
[0022] The cardinality estimation module is configured to perform a similarity query in the cardinality estimation result database based on the range predicate query of the numeric type. If there are similarity query results exceeding the set threshold, the cardinality estimation results obtained are directly reused; if there are no similarity query results exceeding the set threshold, cardinality estimation is performed using a data-driven model.
[0023] A third aspect of the present invention provides a medium having a program stored thereon, which, when executed by a processor, implements the steps in the data-driven like predicate selection rate estimation method as described in the first aspect of the present invention.
[0024] A fourth aspect of the present invention provides an apparatus including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps in the data-driven like predicate selection rate estimation method as described in the first aspect of the present invention.
[0025] The above one or more technical solutions have the following beneficial effects:
[0026] This invention discloses a data-driven method and system for estimating the selectivity of LIKE predicates. It introduces a trie tree to encode the data, ultimately transforming the LIKE predicate into a range predicate that can be processed by the data-driven model. Furthermore, to accelerate the estimation process, a mechanism for reusing cardinality estimation results is proposed. This invention enables rapid cardinality estimation of SQL queries containing LIKE predicates.
[0027] Advantages of additional aspects 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
[0028] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.
[0029] Figure 1 This is a flowchart of the data-driven like predicate selection rate estimation method in Embodiment 1 of the present invention;
[0030] Figure 2 This is a schematic diagram of the trie branch construction for the prefix-type like predicate in Embodiment 1 of the present invention;
[0031] Figure 3 This is a schematic diagram showing the correspondence between the dictionary node ranges and the initial letter information of the prefix-type like predicate in Embodiment 1 of the present invention;
[0032] Figure 4 This is a schematic diagram of the trie branch construction for the suffix-like predicate in Embodiment 1 of the present invention;
[0033] Figure 5 This is a schematic diagram of the data-driven model framework in Embodiment 1 of the present invention;
[0034] Figure 6 This is a schematic diagram illustrating the data-driven model estimation principle in Embodiment 1 of the present invention. Detailed Implementation
[0035] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.
[0036] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.
[0037] Example 1:
[0038] Embodiment 1 of this invention provides a data-driven method for estimating the selectivity of like predicates, such as... Figure 1 As shown, it includes the following steps:
[0039] Step 1: Receive the query statement containing the like predicate and determine the type of the like predicate.
[0040] Step 2: Construct a trie. Based on the type of the like predicate, find the corresponding trie to convert the like predicate query into a range predicate query of numeric type.
[0041] Step 3: Based on the range predicate query of the numeric type, perform a similarity query in the cardinality estimation result database. If there are similarity query results exceeding the set threshold, directly reuse the cardinality estimation results found; if there are no similarity query results exceeding the set threshold, use the data-driven model to perform cardinality estimation.
[0042] In step 1, the types of like predicates include prefix like predicates, suffix like predicates, and substring like predicates. Prefix like predicates begin with "%", suffix like predicates end with "%", and substring like predicates begin and end with "%".
[0043] In step 2, since the data-driven model cannot directly handle selectivity estimation for SQL queries containing the `LIKE` predicate, this embodiment introduces a trie tree to convert SQL queries containing the `LIKE` predicate into range predicate queries involving only numbers. The specific steps for constructing the trie tree are as follows:
[0044] Starting from the root node, determine the number of branches in the first level based on the number of different first letters in all attribute values; then determine the branch nodes in the next level of the trie based on the second letter of each word, and so on, to complete the construction of the trie; after the trie is constructed, encode the words into ranges.
[0045] In one specific implementation, the conversion process for the three main cases of the `like` predicate is as follows:
[0046] (1) Prefix-type like predicate
[0047] For example, `select * from table where word like b%` means to retrieve all rows containing attributes that begin with the letter "b". To convert this type of prefix-based `like` predicate into a range predicate, a tire tree must first be constructed to determine the encoding of each distinct attribute value, i.e., the word. For example... Figure 2 As shown, starting from the root node, let's call it n0. The number of branches in the first level is determined based on the number of different first letters in all attribute values. Figure 2 The entire set of words contains only five characters, and each word begins with either "b" or "d". Therefore, the root node n0 has only two branches: n1, which represents words starting with "b", and n2, which represents words starting with "d". Then, the second letter of each word determines the next level of the trie tree. For example, node n3 represents the branch starting with "ba".
[0048] After construction, the root node represents all four words. In this embodiment, the four words are naturally encoded from 0 to 4, from left to right. Based on the encoding of the root node word, each non-leaf node is labeled with the encoding of its contained leaf nodes, thus forming intervals. Taking node n1 as an example, words encoded from 0 to 1 belong to branches rooted at it, therefore node n1 is labeled with the interval [0,1]. Similarly, all other non-leaf nodes can be labeled with their corresponding intervals. Figure 3 As shown, observing the tire tree reveals that each non-leaf node possesses two sets of information: interval information and initial letter information. The purpose of the tire tree is to map the interval information to the initial letter information through each non-leaf node. Taking node n1 as an example, it means that words starting with the letter "b" are encoded in the interval [0,1]. Similarly, to find words starting with "d", we only need to search node n2, read its information, and then determine that words starting with "d" are encoded in the interval [2,3].
[0049] Thus, this embodiment successfully establishes a bridge for conversion between prefix-type LIKE predicates and pure numeric range predicates. For example, query (1) can be converted into query (2):
[0050] select*from table where word like b% query (1).
[0051] The query is: select * from table where word≤2and word≥0. (2)
[0052] (2) Suffix-like predicate
[0053] For example, `select * from table where word like %t` means to retrieve all rows containing attributes ending with the letter "t". To convert this type of suffix-based `like` predicate into a range predicate, this embodiment still uses a tire tree. Unlike the previous solution for prefix-based `like` predicates, all words need to be reversed first. For example, the word "bat" is converted to "tab". After converting all words, the tire tree is constructed using the method described earlier. For the four words in the vocabulary, the constructed tire tree is as follows: Figure 4 As shown.
[0054] Taking node n3 as an example, it means that words ending with the letter "t" are words encoded in the interval [2,4]. Thus, as... Figure 4 As shown, this embodiment successfully constructs a bridge for conversion between suffix-based LIKE predicates and pure numeric range predicates. For example, query (3) can be converted into query (4):
[0055] select*from table where word like%t query (3).
[0056] The query is: select * from table where word≤4and word≥2. (4)
[0057] (3) Substring-like predicate
[0058] For example: select * from table where word like %a%, means to get all rows containing the letter "a". This includes both prefix and suffix cases. Therefore, it is necessary to search on the previously constructed prefix and suffix tire trees to cover the attributes that meet the predicate conditions to the greatest extent. When searching, follow the level order traversal. If a node containing the target field is found, there is no need to search the child node branches of that node. Due to the limitations of storage space and time complexity, it is not recommended that the prefix and suffix tire trees exceed five levels. Taking query (5) as an example, a five-level tire tree is sufficient to cover the cases where the first three letters or the last three letters contain "a". This is equivalent to completing the "pruning" operation.
[0059] select*from table where word like%a% query (5).
[0060] In step 3, after successfully converting complex SQL queries containing LIKE predicates into numeric range predicate SQL queries that are easier for machine learning models to process, a data-driven estimator capable of handling these SQL queries needs to be built. Therefore, a data-driven model is constructed. The data-driven model is built using an autoregressive model, estimating the cardinality by outputting the probability distribution. The underlying principle of the data-driven model in this embodiment is to use a deep autoregressive model to approximate the joint distribution.
[0061] like Figure 5 As shown, this embodiment designs a selection rate estimator, the core of which is a deep autoregressive model. Each column of a data table in a known database is used as training data and input into the regression model (if the data table is large, a small sample can be input). After training, the regression model outputs the joint data distribution of each column of the data table. Because the data table is used directly as the training sample, the estimator can approximate the joint data distribution in its complete form, without any column independence assumptions. This complete approximation of the joint data distribution not only provides superior accuracy but also eliminates the need to specify which column combinations to base the summary on. Ultimately, this results in a high-precision, compact, and feature-rich selection estimator based on a deep autoregressive model.
[0062] The estimator in this embodiment chooses an autoregressive model for selective estimation primarily because autoregressive models demonstrate superior modeling accuracy when learning information from images, audio, and text. All of these domains involve correlated high-dimensional data similar to relational tables.
[0063] The autoregressive model M applicable to the estimator of this method should have the functional form shown in formula (1).
[0064]
[0065] That is, the input is a tuple, i.e., a data table, and the output is a list of conditional density distributions, each of which is a distribution of the i-th attribute column conditioned on the previous attribute. The scalars needed to calculate the point density are all read from these conditional distributions. A specific example is as follows: Suppose there is a tourism rating table with attributes such as city number, year, star rating, etc. For an autoregressive model, if given an input tuple of the form <102,2017,5>, first, it is vectorized into a form suitable for the model input [E cityno (102),E year (2017), E stars (5)]. Then, they are appropriately aggregated and input into the neural network of each column, as follows: Figure 6 As shown.
[0066] The value 0 can be understood as a starting point and has no actual numerical meaning. Initially, the city number column doesn't have any pre-defined conditional probabilities, so the neural network can directly query the probability distribution of the city number column and find that city number 102 has a selection rate of 0.3. After this, the neural network needs to calculate the conditional probability based on this. This probability clearly depends on the attribute value of the city number. Similarly, the third output depends on the attribute values of the city number and the year, i.e.
[0067] The above steps are based on the formula shown in formula (2), which is the joint distribution formula.
[0068]
[0069] The method in this embodiment does not limit the use of a specific model; any autoregressive model can be inserted to ultimately achieve the function of the estimator. This embodiment presents three representative architectures:
[0070] (1) Masked Autoencoder (MADE), a standard multilayer perceptron, features information masking to ensure autoregressivity.
[0071] (2) ResMADE is a simple extension of MADE, which improves learning efficiency by introducing residual connections.
[0072] (3) Transformer, a type of self-attention model, has driven the latest state-of-the-art progress in the field of natural language processing.
[0073] Under similar parameter counts, more advanced architectures such as (2) and (3) can achieve smaller entropy gaps. However, the nature of cardinality estimation means that smaller entropy gaps do not automatically translate into better selective estimations; instead, they may result in significantly higher computational costs, as in architecture (3). Therefore, the three methods can be selected judiciously.
[0074] Data-driven models can perceive the data distribution in relational tables, exhibiting a significant accuracy advantage over other machine learning-based cardinality estimation methods, such as query-driven models. However, this superior accuracy comes at the cost of higher time complexity. Currently, mainstream data-driven methods do not perform satisfactorily in terms of speed. Therefore, this embodiment proposes a cardinality estimation result reuse mechanism to help accelerate the entire cardinality estimation system.
[0075] This embodiment introduces the concept of query similarity, as shown in the following formula (3):
[0076]
[0077] For two range predicate queries Q and Q′, to obtain their similarity, we need to find all the condition ranges R involved in them. i and R′ i The length of the intersection, i.e., |R i ∩R′ i |, and also requires all conditions involved to be within the range R i and R′ i The length of the union of |R| i ∪R′ i The ratio of these two lengths is the similarity SIM(Q,Q′).
[0078] The query is: select * from table where word≤9 and word≥1. (6)
[0079] The query is: select * from table where word≤12 and word≥2. (7)
[0080] Taking query (6) as an example, the range predicate interval is [1,9], while the range predicate interval of query (7) is [2,12]. Therefore, the intersection of the range predicate intervals of the two queries is [2,9], and the union is [0,12]. Thus, according to formula (3), the similarity between query (6) and query (7) can be calculated to be 8 / 13.
[0081] If the cardinality estimate of query (7) is known at this time, this embodiment sets a threshold using similarity data as an indicator to measure whether the cardinality estimates of query (6) and query (7) can be roughly regarded as the same. Specifically, if the threshold is 0.8, when the similarity between query (6) and query (7) exceeds 0.8, when processing query (6), the time-consuming data-driven model will no longer be used for cardinality estimation. Instead, the cardinality estimate of the already stored query (7) will be directly read as the result of query (6).
[0082] The storage space that holds known cardinality estimates and their corresponding queries (mainly range predicate intervals) is called the cardinality estimate result database. When a new SQL query containing a LIKE predicate needs to be processed, the system first scans the cardinality estimate result database, calculating the similarity between each stored query and the new query. When the first query with a similarity exceeding a threshold is found, the system directly sets the cardinality estimate of that query as the cardinality estimate of the new query, thus skipping the execution of the data-driven model and achieving speed improvement.
[0083] However, not all new queries will find a query with a similarity exceeding a threshold in the cardinality estimation result database during processing, and the cardinality estimation result database cannot occupy too much memory. Moreover, when the cardinality estimation result database stores too many queries, the time cost of scanning and calculating similarity becomes negligible. Therefore, the cardinality estimation result database should store a small number of high-quality queries and have the ability to be updated by swapping in and out queries.
[0084] Therefore, if there are no similarity query results exceeding the set threshold, the cardinality estimation result library is updated based on the cardinality estimation result.
[0085] In this embodiment, to save time, a least recently used strategy is adopted to update the cardinality estimation result database: When a new query enters, the system calculates the similarity between each query in the cardinality estimation result database and the new query. To save time, when the first query with a similarity exceeding the threshold is found, the system marks that query, indicating that its cardinality estimation result has been recently used. If multiple queries have similarities exceeding the threshold, only the first query exceeding the threshold is marked, saving time from scanning subsequent queries and calculating the threshold. If a new query enters, after scanning, if no query in the cardinality estimation result database has a similarity exceeding the threshold with the new query, the system scans the markings of each query in the result database, removes the least recently used query, and replaces it with the new query. This uses a least recently used (LRU) caching mechanism to ensure that the result database contains the most frequently reused query results. After the data-driven model provides the cardinality estimation result for the new query, the result is written into the cardinality estimation result database, completing one update.
[0086] Example 2:
[0087] Embodiment 2 of the present invention provides a data-driven like predicate selection rate estimation system, comprising:
[0088] The statement retrieval module is configured to receive query statements containing the like predicate and determine the type of the like predicate;
[0089] The format conversion module is configured to build a trie and find the corresponding trie based on the type of the like predicate to convert like predicate queries into range predicate queries of numeric type.
[0090] The cardinality estimation module is configured to perform a similarity query in the cardinality estimation result database based on the range predicate query of the numeric type. If there are similarity query results exceeding the set threshold, the cardinality estimation results obtained are directly reused; if there are no similarity query results exceeding the set threshold, cardinality estimation is performed using a data-driven model.
[0091] Example 3:
[0092] Embodiment 3 of the present invention provides a medium on which a program is stored. When the program is executed by a processor, it implements the steps in the data-driven like predicate selection rate estimation method as described in Embodiment 1 of the present invention.
[0093] Example 4:
[0094] Embodiment 4 of the present invention provides a device including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the data-driven like predicate selection rate estimation method as described in Embodiment 1 of the present invention.
[0095] The steps and methods involved in Examples 2, 3 and 4 above correspond to those in Example 1. For specific implementation details, please refer to the relevant description section of Example 1.
[0096] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.
[0097] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.
Claims
1. A data-driven method for estimating the selectivity of like predicates, characterized in that, Includes the following steps: Receive query statements containing the LIKE predicate and determine the type of the LIKE predicate; Constructing a trie involves finding the corresponding trie based on the type of the LIKE predicate, transforming LIKE predicate queries into range predicate queries of numeric types. The specific steps for constructing the trie are as follows: Starting from the root node, determine the number of branches in the first level based on the number of different first letters in all attribute values; then determine the branch nodes in the next level of the trie based on the second letter of each word, and so on, to complete the construction of the trie; after the trie is constructed, encode the words into ranges. Based on the range predicate query of the numeric type, a similarity query is performed in the cardinality estimation result database. If there are similarity query results that exceed the set threshold, the cardinality estimation results obtained from the query are directly reused. If there are no similarity query results exceeding the set threshold, cardinality estimation is performed using a data-driven model. This involves measuring the similarity between two query statements by calculating the length of the intersection and union of the range intervals and then calculating the ratio. If there are no similarity query results exceeding the set threshold, the cardinality estimation result database is updated based on the cardinality estimation results. The least recently used strategy is used to update the cardinality estimation result database. If a new query enters, after scanning, if the first query with similarity exceeding the threshold is found, the system will mark the first query with similarity exceeding the threshold. If a new query is entered, after scanning, if no query in the cardinality estimation result library has a similarity to the new query exceeding the threshold, the system will scan the tags of each query in the result library, remove the least recently used query, replace it with the new query, and write the result into the cardinality estimation result library after the data-driven model provides the cardinality estimation result for the new query, thus completing an update.
2. The data-driven like predicate selection rate estimation method as described in claim 1, characterized in that, The types of like predicates include prefix like predicates, suffix like predicates, and substring like predicates.
3. The data-driven like predicate selection rate estimation method as described in claim 1, characterized in that, The data-driven model is constructed using an autoregressive model and estimates the cardinality by outputting the probability distribution.
4. A data-driven like predicate selection rate estimation system, characterized in that, include: The statement retrieval module is configured to receive query statements containing the like predicate and determine the type of the like predicate; The format conversion module is configured to build a trie. Based on the type of the `LIKE` predicate, it finds the corresponding trie to convert `LIKE` predicate queries into numeric range predicate queries. The specific steps for building the trie are as follows: Starting from the root node, determine the number of branches in the first level based on the number of different first letters in all attribute values; then determine the branch nodes in the next level of the trie based on the second letter of each word, and so on, to complete the construction of the trie; after the trie is constructed, encode the words into ranges. The cardinality estimation module is configured to perform a similarity query in the cardinality estimation result database based on the range predicate query of the numeric type. If there are similarity query results that exceed the set threshold, the cardinality estimation results obtained from the query are directly reused. If there are no similarity query results exceeding the set threshold, cardinality estimation is performed using a data-driven model. This involves measuring the similarity between two query statements by calculating the length of the intersection and union of the range intervals and then calculating the ratio. If there are no similarity query results exceeding the set threshold, the cardinality estimation result database is updated based on the cardinality estimation results. The least recently used strategy is used to update the cardinality estimation result database. If a new query enters, after scanning, if the first query with similarity exceeding the threshold is found, the system will mark the first query with similarity exceeding the threshold. If a new query is entered, after scanning, if no query in the cardinality estimation result library has a similarity to the new query exceeding the threshold, the system will scan the tags of each query in the result library, remove the least recently used query, replace it with the new query, and write the result into the cardinality estimation result library after the data-driven model provides the cardinality estimation result for the new query, thus completing an update.
5. A computer-readable storage medium, characterized in that, It stores multiple instructions, which are adapted to be loaded and executed by the processor of the terminal device, according to any one of claims 1-3, the data-driven like predicate selection rate estimation method.
6. A terminal device, characterized in that, It includes a processor and a computer-readable storage medium, the processor being used to implement various instructions; the computer-readable storage medium being used to store multiple instructions adapted to be loaded by the processor and executed by the processor for the data-driven like predicate selection rate estimation method according to any one of claims 1-3.