mirror of
https://github.com/MariaDB/server.git
synced 2025-09-27 11:29:12 +02:00
16f2b7e3df
Introduces NO_INDEX_MERGE and INDEX_MERGE, which control whether or
not index merge strategies are used during query optimization. Here
is an example query from the tests:
SET optimizer_switch='index_merge_intersection=off';
EXPLAIN SELECT /*+ INDEX_MERGE(t1 f4, f2) */ COUNT(*) FROM t1
WHERE f4 = 'h' AND f2 = 2;
with the hint in place, the query plan will employ the index_merge
intersect strategy (abbreviated EXPLAIN output):
type Extra
index_merge Using intersect(f2,f4); Using where; Using index
The presence of the [NO_]INDEX_MERGE hint overrides the optimizer's
choice of keys during the index merge optimization. As we see in
the above example, keys f2 and f4 and given and the optimizer will
consider only those keys for this query.
When the hint is given without any particular keys, as in
INDEX_MERGE(table), then all keys are considered. In this case, the
cheapest index merge among the keys should be used. When
NO_INDEX_MERGE(table) is given, then index merge is disabled for
that table.
When the hint is given with one or more keys, then only those keys
are considered. In the case of NO_INDEX_MERGE, those keys are
excluded. This can lead to no merged indexes at all, because
there may not be sufficient row-ordered read columns available for
consideration.
The index merge strategies of intersection, union, and sort union
cannot themselves be directly controlled via the hints. In combination
with the optimizer switches for the same, the strategy may be
indirectly controlled but this is not guaranteed.
When the hint directs the optimizer such that insufficient ROR scans
are available, thus leading to a situation where the INDEX_MERGE hint
cannot be honored, the server will emit a warning to that effect.
In the hints module (opt_hints*{cc,h}), this commit adds some
index merge-specific functionality to make interpreting hint state
at callsites in the optimizer cleaner and more intuitive.
Particularly, we add a bit field to the table hints class which
indicates the keys that are marked by an [NO_]INDEX_MERGE hint, if
present. A new function, index_merge_hint (and associated new
helper functions) relies on this field when interpreting index merge
hint state for the optimizer.
If there are no index merges available prior to attemping to find
a suitable union/sort union, then the optimizer will not attempt
it. This change results in optimizer trace output which does not
include the 'analyzing_index_merge_union' block when there are no
merges.
Parts of this implementation based on MySQL commit
ebcb981807e3d91a64782e89d48e1a25622eafea
54 lines
1.4 KiB
Text
54 lines
1.4 KiB
Text
create or replace table t1 (col1 char(10) character set ucs2, filler char(100), key(col1)) ;
|
|
insert into t1 values ('a', 'a');
|
|
insert into t1 values ('a', 'a');
|
|
set optimizer_trace=1;
|
|
explain format=json select * from t1 force index(col1) where col1 >='a';
|
|
EXPLAIN
|
|
{
|
|
"query_block": {
|
|
"select_id": 1,
|
|
"cost": "COST_REPLACED",
|
|
"nested_loop": [
|
|
{
|
|
"table": {
|
|
"table_name": "t1",
|
|
"access_type": "range",
|
|
"possible_keys": ["col1"],
|
|
"key": "col1",
|
|
"key_length": "21",
|
|
"used_key_parts": ["col1"],
|
|
"loops": 1,
|
|
"rows": 2,
|
|
"cost": "COST_REPLACED",
|
|
"filtered": 100,
|
|
"index_condition": "t1.col1 >= 'a'"
|
|
}
|
|
}
|
|
]
|
|
}
|
|
}
|
|
select JSON_DETAILED(JSON_EXTRACT(trace, '$**.analyzing_range_alternatives')) AS JS from INFORMATION_SCHEMA.OPTIMIZER_TRACE;
|
|
JS
|
|
[
|
|
{
|
|
"range_scan_alternatives":
|
|
[
|
|
{
|
|
"index": "col1",
|
|
"ranges":
|
|
["(a) <= (col1)"],
|
|
"rowid_ordered": false,
|
|
"using_mrr": false,
|
|
"index_only": false,
|
|
"rows": 2,
|
|
"cost": 0.003808422,
|
|
"chosen": true
|
|
}
|
|
],
|
|
"analyzing_roworder_intersect":
|
|
{
|
|
"cause": "too few roworder scans"
|
|
}
|
|
}
|
|
]
|
|
drop table t1;
|