Rechercher dans le manuel MySQL
8.2.1.4 Engine Condition Pushdown Optimization
This optimization improves the efficiency of direct
comparisons between a nonindexed column and a constant. In
such cases, the condition is “pushed down” to the
storage engine for evaluation. This optimization can be used
only by the NDB
storage engine.
For NDB Cluster, this optimization can eliminate the need to send nonmatching rows over the network between the cluster's data nodes and the MySQL server that issued the query, and can speed up queries where it is used by a factor of 5 to 10 times over cases where condition pushdown could be but is not used.
Suppose that an NDB Cluster table is defined as follows:
Condition pushdown can be used with queries such as the one shown here, which includes a comparison between a nonindexed column and a constant:
The use of condition pushdown can be seen in the output of
EXPLAIN
:
However, condition pushdown cannot be used with either of these two queries:
Condition pushdown is not applicable to the first query
because an index exists on column a
. (An
index access method would be more efficient and so would be
chosen in preference to condition pushdown.) Condition
pushdown cannot be employed for the second query because the
comparison involving the nonindexed column
b
is indirect. (However, condition pushdown
could be applied if you were to reduce b + 1 =
10
to b = 9
in the
WHERE
clause.)
Condition pushdown may also be employed when an indexed column
is compared with a constant using a >
or
<
operator:
Other supported comparisons for condition pushdown include the following:
column
[NOT] LIKEpattern
pattern
must be a string literal containing the pattern to be matched; for syntax, see Section 12.5.1, “String Comparison Functions and Operators”.column
IS [NOT] NULLcolumn
IN (value_list
)Each item in the
value_list
must be a constant, literal value.column
BETWEENconstant1
ANDconstant2
constant1
andconstant2
must each be a constant, literal value.
In all of the cases in the preceding list, it is possible for the condition to be converted into the form of one or more direct comparisons between a column and a constant.
Engine condition pushdown is enabled by default. To disable it
at server startup, set the
optimizer_switch
system
variable. For example, in a my.cnf
file,
use these lines:
[mysqld]
optimizer_switch=engine_condition_pushdown=off
At runtime, disable condition pushdown like this:
Limitations. Engine condition pushdown is subject to the following limitations:
Condition pushdown is supported only by the
NDB
storage engine.Columns may be compared with constants only; however, this includes expressions which evaluate to constant values.
Columns used in comparisons cannot be of any of the
BLOB
orTEXT
types.A string value to be compared with a column must use the same collation as the column.
Joins are not directly supported; conditions involving multiple tables are pushed separately where possible. Use extended
EXPLAIN
output to determine which conditions are actually pushed down. See Section 8.8.3, “Extended EXPLAIN Output Format”.
Previously, condition pushdown was limited to terms referring to column values from the same table to which the condition was being pushed. Beginning with NDB 8.0.16, column values from tables earlier in the query plan can also be referred to from pushed conditions. This reduces the number of rows which must be handled by the SQL node during join processing. Filtering can be also performed in parallel in the LDM threads, rather than in a single mysqld process. This has the potential to improve performance of queries by a significant margin.
Join algorithms cannot be combined with referring columns from previous tables in the following two situations:
When any of the referred previous tables are in a join buffer. In this case, each row retrieved from the scan-filtered table is matched against every row in the buffer. This means that there is no single specific row from which column values can be fetched from when generating the scan filter.
When the column originates from a child operation in a pushed join. This is because rows referenced from ancestor operations in the join have not yet been retrieved when the scan filter is generated.
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-condition-pushdown-optimization.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.