Rechercher dans le manuel MySQL
8.9.3 Optimizer Hints
One means of control over optimizer strategies is to set the
optimizer_switch
system
variable (see Section 8.9.2, “Switchable Optimizations”).
Changes to this variable affect execution of all subsequent
queries; to affect one query differently from another, it's
necessary to change
optimizer_switch
before each
one.
Another way to control the optimizer is by using optimizer
hints, which can be specified within individual statements.
Because optimizer hints apply on a per-statement basis, they
provide finer control over statement execution plans than can be
achieved using
optimizer_switch
. For example,
you can enable an optimization for one table in a statement and
disable the optimization for a different table. Hints within a
statement take precedence over
optimizer_switch
flags.
Examples:
- SELECT /*+ NO_RANGE_OPTIMIZATION(t3 PRIMARY, f2_idx) */ f1
Optimizer hints, described here, differ from index hints, described in Section 8.9.4, “Index Hints”. Optimizer and index hints may be used separately or together.
Optimizer Hint Overview
Optimizer hints apply at different scope levels:
Global: The hint affects the entire statement
Query block: The hint affects a particular query block within a statement
Table-level: The hint affects a particular table within a query block
Index-level: The hint affects a particular index within a table
The following table summarizes the available optimizer hints, the optimizer strategies they affect, and the scope or scopes at which they apply. More details are given later.
Table 8.2 Optimizer Hints Available
Hint Name | Description | Applicable Scopes |
---|---|---|
BKA ,
NO_BKA |
Affects Batched Key Access join processing | Query block, table |
BNL ,
NO_BNL |
Affects Block Nested-Loop join processing | Query block, table |
INDEX_MERGE ,
NO_INDEX_MERGE |
Affects Index Merge optimization | Table, index |
JOIN_FIXED_ORDER |
Use table order specified in FROM clause for join
order |
Query block |
JOIN_ORDER |
Use table order specified in hint for join order | Query block |
JOIN_PREFIX |
Use table order specified in hint for first tables of join order | Query block |
JOIN_SUFFIX |
Use table order specified in hint for last tables of join order | Query block |
MAX_EXECUTION_TIME |
Limits statement execution time | Global |
MERGE ,
NO_MERGE |
Affects derived table/view merging into outer query block | Table |
MRR ,
NO_MRR |
Affects Multi-Range Read optimization | Table, index |
NO_ICP |
Affects Index Condition Pushdown optimization | Table, index |
NO_RANGE_OPTIMIZATION |
Affects range optimization | Table, index |
QB_NAME |
Assigns name to query block | Query block |
RESOURCE_GROUP |
Set resource group during statement execution | Global |
SEMIJOIN ,
NO_SEMIJOIN |
Affects semijoin strategies; beginning with MySQL 8.0.17, this also applies to antijoins | Query block |
SKIP_SCAN ,
NO_SKIP_SCAN |
Affects Skip Scan optimization | Table, index |
SET_VAR |
Set variable during statement execution | Global |
SUBQUERY |
Affects materialization,
IN -to-EXISTS
subquery stratgies |
Query block |
Disabling an optimization prevents the optimizer from using it. Enabling an optimization means the optimizer is free to use the strategy if it applies to statement execution, not that the optimizer necessarily will use it.
MySQL supports comments in SQL statements as described in
Section 9.6, “Comment Syntax”. Optimizer hints must be specified
within /*+ ... */
comments. That is,
optimizer hints use a variant of /* ... */
C-style comment syntax, with a +
character
following the /*
comment opening sequence.
Examples:
- /*+ BKA(t1) */
- /*+ BNL(t1, t2) */
- /*+ NO_RANGE_OPTIMIZATION(t4 PRIMARY) */
- /*+ QB_NAME(qb2) */
Whitespace is permitted after the +
character.
The parser recognizes optimizer hint comments after the
initial keyword of SELECT
,
UPDATE
,
INSERT
,
REPLACE
, and
DELETE
statements. Hints are
permitted in these contexts:
At the beginning of query and data change statements:
At the beginning of query blocks:
In hintable statements prefaced by
EXPLAIN
. For example:The implication is that you can use
EXPLAIN
to see how optimizer hints affect execution plans. UseSHOW WARNINGS
immediately afterEXPLAIN
to see how hints are used. The extendedEXPLAIN
output displayed by a followingSHOW WARNINGS
indicates which hints were used. Ignored hints are not displayed.
A hint comment may contain multiple hints, but a query block cannot contain multiple hint comments. This is valid:
- SELECT /*+ BNL(t1) BKA(t2) */ ...
But this is invalid:
When a hint comment contains multiple hints, the possibility of duplicates and conflicts exists. The following general guidelines apply. For specific hint types, additional rules may apply, as indicated in the hint descriptions.
Duplicate hints: For a hint such as
/*+ MRR(idx1) MRR(idx1) */
, MySQL uses the first hint and issues a warning about the duplicate hint.Conflicting hints: For a hint such as
/*+ MRR(idx1) NO_MRR(idx1) */
, MySQL uses the first hint and issues a warning about the second conflicting hint.
Query block names are identifiers and follow the usual rules about what names are valid and how to quote them (see Section 9.2, “Schema Object Names”).
Hint names, query block names, and strategy names are not case sensitive. References to table and index names follow the usual identifier case sensitivity rules (see Section 9.2.2, “Identifier Case Sensitivity”).
Join-order hints affect the order in which the optimizer joins tables.
Syntax of the
JOIN_FIXED_ORDER
hint:
- hint_name([@query_block_name])
Syntax of other join-order hints:
- hint_name([@query_block_name] tbl_name [, tbl_name] ...)
- hint_name(tbl_name[@query_block_name] [, tbl_name[@query_block_name]] ...)
The syntax refers to these terms:
hint_name
: These hint names are permitted:JOIN_FIXED_ORDER
: Force the optimizer to join tables using the order in which they appear in theFROM
clause. This is the same as specifyingSELECT STRAIGHT_JOIN
.JOIN_ORDER
: Instruct the optimizer to join tables using the specified table order. The hint applies to the named tables. The optimizer may place tables that are not named anywhere in the join order, including between specified tables.JOIN_PREFIX
: Instruct the optimizer to join tables using the specified table order for the first tables of the join execution plan. The hint applies to the named tables. The optimizer places all other tables after the named tables.JOIN_SUFFIX
: Instruct the optimizer to join tables using the specified table order for the last tables of the join execution plan. The hint applies to the named tables. The optimizer places all other tables before the named tables.
tbl_name
: The name of a table used in the statement. A hint that names tables applies to all tables that it names. TheJOIN_FIXED_ORDER
hint names no tables and applies to all tables in theFROM
clause of the query block in which it occurs.If a table has an alias, hints must refer to the alias, not the table name.
Table names in hints cannot be qualified with schema names.
query_block_name
: The query block to which the hint applies. If the hint includes no leading@
, the hint applies to the query block in which it occurs. Forquery_block_name
syntax, the hint applies to the named table in the named query block. To assign a name to a query block, see Optimizer Hints for Naming Query Blocks.tbl_name
@query_block_name
Example:
- /*+ JOIN_PREFIX(t2, t5@subq2, t4@subq1)
- JOIN_ORDER(t4@subq1, t3)
- JOIN_SUFFIX(t1) */
Hints control the behavior of semijoin tables that are merged
to the outer query block. If subqueries
subq1
and subq2
are
converted to semijoins, tables t4@subq1
and
t5@subq2
are merged to the outer query
block. In this case, the hint specified in the outer query
block controls the behavior of t4@subq1
,
t5@subq2
tables.
The optimizer resolves join-order hints according to these principles:
Multiple hint instances
Only one
JOIN_PREFIX
andJOIN_SUFFIX
hint of each type are applied. Any later hints of the same type are ignored with a warning.JOIN_ORDER
can be specified several times.Examples:
- /*+ JOIN_PREFIX(t1) JOIN_PREFIX(t2) */
The second
JOIN_PREFIX
hint is ignored with a warning.- /*+ JOIN_PREFIX(t1) JOIN_SUFFIX(t2) */
Both hints are applicable. No warning occurs.
- /*+ JOIN_ORDER(t1, t2) JOIN_ORDER(t2, t3) */
Both hints are applicable. No warning occurs.
Conflicting hints
In some cases hints can conflict, such as when
JOIN_ORDER
andJOIN_PREFIX
have table orders that are impossible to apply at the same time:In this case, the first specified hint is applied and subsequent conflicting hints are ignored with no warning. A valid hint that is impossible to apply is silently ignored with no warning.
Ignored hints
A hint is ignored if a table specified in the hint has a circular dependency.
Example:
- /*+ JOIN_ORDER(t1, t2) JOIN_PREFIX(t2, t1) */
The
JOIN_ORDER
hint sets tablet2
dependent ont1
. TheJOIN_PREFIX
hint is ignored because tablet1
cannot be dependent ont2
. Ignored hints are not displayed in extendedEXPLAIN
output.Interaction with
const
tablesThe MySQL optimizer places
const
tables first in the join order, and the position of aconst
table cannot be affected by hints. References toconst
tables in join-order hints are ignored, although the hint is still applicable. For example, these are equivalent:- JOIN_ORDER(t1, const_tbl, t2)
- JOIN_ORDER(t1, t2)
Accepted hints shown in extended
EXPLAIN
output includeconst
tables as they were specified.Interaction with types of join operations
MySQL supports several type of joins:
LEFT
,RIGHT
,INNER
,CROSS
,STRAIGHT_JOIN
. A hint that conflicts with the specified type of join is ignored with no warning.Example:
Here a conflict occurs between the requested join order in the hint and the order required by the
LEFT JOIN
. The hint is ignored with no warning.
Table-level hints affect:
Use of the Block Nested-Loop (BNL) and Batched Key Access (BKA) join-processing algorithms (see Section 8.2.1.11, “Block Nested-Loop and Batched Key Access Joins”).
Whether derived tables, view references, or common table expressions should be merged into the outer query block, or materialized using an internal temporary table.
These hint types apply to specific tables, or all tables in a query block.
Syntax of table-level hints:
- hint_name([@query_block_name] [tbl_name [, tbl_name] ...])
- hint_name([tbl_name@query_block_name [, tbl_name@query_block_name] ...])
The syntax refers to these terms:
hint_name
: These hint names are permitted:NoteTo use a BNL or BKA hint to enable join buffering for any inner table of an outer join, join buffering must be enabled for all inner tables of the outer join.
tbl_name
: The name of a table used in the statement. The hint applies to all tables that it names. If the hint names no tables, it applies to all tables of the query block in which it occurs.If a table has an alias, hints must refer to the alias, not the table name.
Table names in hints cannot be qualified with schema names.
query_block_name
: The query block to which the hint applies. If the hint includes no leading@
, the hint applies to the query block in which it occurs. Forquery_block_name
syntax, the hint applies to the named table in the named query block. To assign a name to a query block, see Optimizer Hints for Naming Query Blocks.tbl_name
@query_block_name
Examples:
A table-level hint applies to tables that receive records from previous tables, not sender tables. Consider this statement:
If the optimizer chooses to process t1
first, it applies a Block Nested-Loop join to
t2
by buffering the rows from
t1
before starting to read from
t2
. If the optimizer instead chooses to
process t2
first, the hint has no effect
because t2
is a sender table.
For the MERGE
and
NO_MERGE
hints, these
precedence rules apply:
A hint takes precedence over any optimizer heuristic that is not a technical constraint. (If providing a hint as a suggestion has no effect, the optimizer has a reason for ignoring it.)
A hint takes precedence over the
derived_merge
flag of theoptimizer_switch
system variable.For view references, an
ALGORITHM={MERGE|TEMPTABLE}
clause in the view definition takes precedence over a hint specified in the query referencing the view.
Index-level hints affect which index-processing strategies the optimizer uses for particular tables or indexes. These hint types affect use of Index Condition Pushdown (ICP), Multi-Range Read (MRR), Index Merge, and range optimizations (see Section 8.2.1, “Optimizing SELECT Statements”).
Syntax of index-level hints:
- hint_name([@query_block_name] tbl_name [index_name [, index_name] ...])
- hint_name(tbl_name@query_block_name [index_name [, index_name] ...])
The syntax refers to these terms:
hint_name
: These hint names are permitted:INDEX_MERGE
,NO_INDEX_MERGE
: Enable or disable the Index Merge access method for the specified table or indexes. For information about this access method, see Section 8.2.1.3, “Index Merge Optimization”. These hints apply to all three Index Merge algorithms.The
INDEX_MERGE
hint forces the optimizer to use Index Merge for the specified table using the specified set of indexes. If no index is specified, the optimizer considers all possible index combinations and selects the least expensive one. The hint may be ignored if the index combination is inapplicable to the given statement.The
NO_INDEX_MERGE
hint disables Index Merge combinations that involve any of the specified indexes. If the hint specifies no indexes, Index Merge is not permitted for the table.MRR
,NO_MRR
: Enable or disable MRR for the specified table or indexes. MRR hints apply only toInnoDB
andMyISAM
tables. For information about this access method, see Section 8.2.1.10, “Multi-Range Read Optimization”.NO_ICP
: Disable ICP for the specified table or indexes. By default, ICP is a candidate optimization strategy, so there is no hint for enabling it. For information about this access method, see Section 8.2.1.5, “Index Condition Pushdown Optimization”.NO_RANGE_OPTIMIZATION
: Disable index range access for the specified table or indexes. This hint also disables Index Merge and Loose Index Scan for the table or indexes. By default, range access is a candidate optimization strategy, so there is no hint for enabling it.This hint may be useful when the number of ranges may be high and range optimization would require many resources.
SKIP_SCAN
,NO_SKIP_SCAN
: Enable or disable the Skip Scan access method for the specified table or indexes. For information about this access method, see Skip Scan Range Access Method. These hints are available as of MySQL 8.0.13.The
SKIP_SCAN
hint forces the optimizer to use Skip Scan for the specified table using the specified set of indexes. If no index is specified, the optimizer considers all possible indexes and selects the least expensive one. The hint may be ignored if the index is inapplicable to the given statement.The
NO_SKIP_SCAN
hint disables Skip Scan for the specified indexes. If the hint specifies no indexes, Skip Scan is not permitted for the table.
tbl_name
: The table to which the hint applies.index_name
: The name of an index in the named table. The hint applies to all indexes that it names. If the hint names no indexes, it applies to all indexes in the table.To refer to a primary key, use the name
PRIMARY
. To see the index names for a table, useSHOW INDEX
.query_block_name
: The query block to which the hint applies. If the hint includes no leading@
, the hint applies to the query block in which it occurs. Forquery_block_name
syntax, the hint applies to the named table in the named query block. To assign a name to a query block, see Optimizer Hints for Naming Query Blocks.tbl_name
@query_block_name
Examples:
- SELECT /*+ NO_RANGE_OPTIMIZATION(t3 PRIMARY, f2_idx) */ f1
The following examples use the Index Merge hints, but other
index-level hints follow the same principles regarding hint
ignoring and precedence of optimizer hints in relation to the
optimizer_switch
system
variable or index hints.
Assume that table t1
has columns
a
, b
,
c
, and d
; and that
indexes named i_a
, i_b
,
and i_c
exist on a
,
b
, and c
, respectively:
Index Merge is used for (i_a, i_b, i_c)
in
this case.
Index Merge is used for (i_b, i_c)
in this
case.
- /*+ INDEX_MERGE(t1 i_a, i_b) NO_INDEX_MERGE(t1 i_b) */
NO_INDEX_MERGE
is ignored
because there is a preceding hint for the same table.
- /*+ NO_INDEX_MERGE(t1 i_a, i_b) INDEX_MERGE(t1 i_b) */
INDEX_MERGE
is ignored
because there is a preceding hint for the same table.
For the INDEX_MERGE
and
NO_INDEX_MERGE
optimizer
hints, these precedence rules apply:
If an optimizer hint is specified and is applicable, it takes precedence over the Index Merge-related flags of the
optimizer_switch
system variable.The hint takes precedence over
optimizer_switch
. Index Merge is used for(i_b, i_c)
in this case.The hint specifies only one index, so it is inapplicable, and the
optimizer_switch
flag (on
) applies. Index Merge is used if the optimizer assesses it to be cost efficient.The hint specifies only one index, so it is inapplicable, and the
optimizer_switch
flag (off
) applies. Index Merge is not used.The
USE INDEX
,FORCE INDEX
, andIGNORE INDEX
index hints have higher priority than theINDEX_MERGE
andNO_INDEX_MERGE
optimizer hints.IGNORE INDEX
takes precedence overINDEX_MERGE
, so indexi_a
is excluded from the possible ranges for Index Merge.Index Merge is disallowed for
i_a, i_b
because ofFORCE INDEX
, but the optimizer is forced to use eitheri_a
ori_b
forrange
orref
access. There are no conflicts; both hints are applicable.If an
IGNORE INDEX
hint names multiple indexes, those indexes are unavailable for Index Merge.The
FORCE INDEX
andUSE INDEX
hints make only the named indexes to be available for Index Merge.The Index Merge intersection access algorithm is used for
(i_a, i_b)
. The same is true ifFORCE INDEX
is changed toUSE INDEX
.
Subquery hints affect whether to use semijoin transformations
and which semijoin strategies to permit, and, when semijoins
are not used, whether to use subquery materialization or
IN
-to-EXISTS
transformations. For more information about these
optimizations, see Section 8.2.2, “Optimizing Subqueries, Derived Tables, View References, and Common Table
Expressions”.
Syntax of hints that affect semijoin strategies:
- hint_name([@query_block_name] [strategy [, strategy] ...])
The syntax refers to these terms:
hint_name
: These hint names are permitted:SEMIJOIN
,NO_SEMIJOIN
: Enable or disable the named semijoin strategies.
strategy
: A semijoin strategy to be enabled or disabled. These strategy names are permitted:DUPSWEEDOUT
,FIRSTMATCH
,LOOSESCAN
,MATERIALIZATION
.For
SEMIJOIN
hints, if no strategies are named, semijoin is used if possible based on the strategies enabled according to theoptimizer_switch
system variable. If strategies are named but inapplicable for the statement,DUPSWEEDOUT
is used.For
NO_SEMIJOIN
hints, if no strategies are named, semijoin is not used. If strategies are named that rule out all applicable strategies for the statement,DUPSWEEDOUT
is used.
If one subquery is nested within another and both are merged
into a semijoin of an outer query, any specification of
semijoin strategies for the innermost query are ignored.
SEMIJOIN
and
NO_SEMIJOIN
hints can still
be used to enable or disable semijoin transformations for such
nested subqueries.
If DUPSWEEDOUT
is disabled, on occasion the
optimizer may generate a query plan that is far from optimal.
This occurs due to heuristic pruning during greedy search,
which can be avoided by setting
optimizer_prune_level=0
.
Examples:
Syntax of hints that affect whether to use subquery
materialization or
IN
-to-EXISTS
transformations:
- SUBQUERY([@query_block_name] strategy)
The hint name is always
SUBQUERY
.
For SUBQUERY
hints, these
strategy
values are permitted:
INTOEXISTS
,
MATERIALIZATION
.
Examples:
For semijoin and SUBQUERY
hints, a leading
@
specifies the query block to which the hint applies. If the
hint includes no leading
query_block_name
@
,
the hint applies to the query block in which it occurs. To
assign a name to a query block, see
Optimizer Hints for Naming Query Blocks.
query_block_name
If a hint comment contains multiple subquery hints, the first is used. If there are other following hints of that type, they produce a warning. Following hints of other types are silently ignored.
The MAX_EXECUTION_TIME
hint
is permitted only for SELECT
statements. It places a limit N
(a
timeout value in milliseconds) on how long a statement is
permitted to execute before the server terminates it:
- MAX_EXECUTION_TIME(N)
Example with a timeout of 1 second (1000 milliseconds):
The
MAX_EXECUTION_TIME(
hint sets a statement execution timeout of
N
)N
milliseconds. If this option is
absent or N
is 0, the statement
timeout established by the
max_execution_time
system
variable applies.
The MAX_EXECUTION_TIME
hint
is applicable as follows:
For statements with multiple
SELECT
keywords, such as unions or statements with subqueries,MAX_EXECUTION_TIME
applies to the entire statement and must appear after the firstSELECT
.It applies to read-only
SELECT
statements. Statements that are not read only are those that invoke a stored function that modifies data as a side effect.It does not apply to
SELECT
statements in stored programs and is ignored.
The SET_VAR
hint sets the
session value of a system variable temporarily (for the
duration of a single statement). Examples:
Syntax of the SET_VAR
hint:
var_name
names a system variable
that has a session value (although not all such variables can
be named, as explained later).
value
is the value to assign to the
variable; the value must be a scalar.
SET_VAR
makes a temporary
variable change, as demonstrated by these statements:
- +-----------------+
- | @@unique_checks |
- +-----------------+
- | 1 |
- +-----------------+
- +-----------------+
- | @@unique_checks |
- +-----------------+
- | 0 |
- +-----------------+
- +-----------------+
- | @@unique_checks |
- +-----------------+
- | 1 |
- +-----------------+
With SET_VAR
, there is no
need to save and restore the variable value. This enables you
to replace multiple statements by a single statement. Consider
this sequence of statements:
- SELECT ...
The sequence can be replaced by this single statement:
- SELECT /*+ SET_VAR(var_name = value) ...
Standalone
SET
statements permit any of these syntaxes for naming session
variables:
Because the SET_VAR
hint
applies only to session variables, session scope is implicit,
and SESSION
, @@SESSION.
,
and @@
are neither needed nor permitted.
Including explicit session-indicator syntax results in the
SET_VAR
hint being ignored
with a warning.
Not all session variables are permitted for use with
SET_VAR
. Individual system
variable descriptions indicate whether each variable is
hintable; see Section 5.1.8, “Server System Variables”. You
can also check a system variable at runtime by attempting to
use it with SET_VAR
. If the
variable is not hintable, a warning occurs:
- +---+
- | 1 |
- +---+
- | 1 |
- +---+
- *************************** 1. row ***************************
- Level: Warning
- Code: 4537
SET_VAR
syntax permits
setting only a single variable, but multiple hints can be
given to set multiple variables:
- SELECT /*+ SET_VAR(optimizer_switch = 'mrr_cost_based=off')
- SET_VAR(max_heap_table_size = 1G) */ 1;
If several hints with the same variable name appear in the same statement, the first one is applied and the others are ignored with a warning:
- SELECT /*+ SET_VAR(max_heap_table_size = 1G)
- SET_VAR(max_heap_table_size = 3G) */ 1;
In this case, the second hint is ignored with a warning that it is conflicting.
A SET_VAR
hint is ignored
with a warning if no system variable has the specified name or
the variable value is incorrect:
For the first statement, there is no
max_size
variable. For the second
statement, mrr_cost_flag
takes values of
on
or off
, so attempting
to set it to yes
is incorrect. In each
case, the hint is ignored with a warning.
The SET_VAR
hint is
permitted only at the statement level. If used in a subquery,
the hint is ignored with a warning.
Slave servers ignore SET_VAR
hints in replicated statements to avoid the potential for
security issues.
The RESOURCE_GROUP
optimizer
hint is used for resource group management (see
Section 8.12.5, “Resource Groups”). This hint assigns the
thread that executes a statement to the named resource group
temporarily (for the duration of the statement). It requires
the RESOURCE_GROUP_ADMIN
or
RESOURCE_GROUP_USER
privilege.
Examples:
Syntax of the RESOURCE_GROUP
hint:
- RESOURCE_GROUP(group_name)
group_name
indicates the resource
group to which the thread should be assigned for the duration
of statement execution. If the group is nonexistent, a warning
occurs and the hint is ignored.
The RESOURCE_GROUP
hint must
appear after the initial statement keyword
(SELECT
, INSERT
,
REPLACE
, UPDATE
, or
DELETE
).
An alternative to
RESOURCE_GROUP
is the
SET RESOURCE GROUP
statement,
which nontemporarily assigns threads to a resource group. See
Section 13.7.2.4, “SET RESOURCE GROUP Syntax”.
Table-level, index-level, and subquery optimizer hints permit
specific query blocks to be named as part of their argument
syntax. To create these names, use the
QB_NAME
hint, which assigns
a name to the query block in which it occurs:
- QB_NAME(name)
QB_NAME
hints can be used to
make explicit in a clear way which query blocks other hints
apply to. They also permit all non-query block name hints to
be specified within a single hint comment for easier
understanding of complex statements. Consider the following
statement:
QB_NAME
hints assign names
to query blocks in the statement:
- SELECT /*+ QB_NAME(qb1) */ ...
Then other hints can use those names to refer to the appropriate query blocks:
- SELECT /*+ QB_NAME(qb1) MRR(@qb1 t1) BKA(@qb2) NO_MRR(@qb3t1 idx1, id2) */ ...
The resulting effect is as follows:
MRR(@qb1 t1)
applies to tablet1
in query blockqb1
.BKA(@qb2)
applies to query blockqb2
.NO_MRR(@qb3 t1 idx1, id2)
applies to indexesidx1
andidx2
in tablet1
in query blockqb3
.
Query block names are identifiers and follow the usual rules about what names are valid and how to quote them (see Section 9.2, “Schema Object Names”). For example, a query block name that contains spaces must be quoted, which can be done using backticks:
If the ANSI_QUOTES
SQL mode
is enabled, it is also possible to quote query block names
within double quotation marks:
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-optimizer-hints.html/
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.