Query Block Naming

Optimizer hints can address certain named query blocks within the query. Query block is either a top-level SELECT/UPDATE/DELETE statement or a subquery within the statement.

There are three ways to address query blocks:

  • by an explicit name assigned using QB_NAME() hint

  • by implicit name based on position of the query block in the query

  • by implicit name based on alias of derived table, view or CTE

Explicit Query Block Names

  • QB_NAME(query_block_name) hint is used to assign a name to a query block in which this hint is placed.

Examples

Assigning a name to a top-level SELECT statement:

SELECT /*+ QB_NAME(foo) */ * FROM t1 ...;

Assigning a name to a subquery:

SELECT * FROM (SELECT /*+ QB_NAME(subq) */* FROM t1 ...) dt ...;

Assigning names to multiple query blocks:

SELECT /*+ QB_NAME(qb_outer) */ ...
  FROM (SELECT /*+ QB_NAME(dt1) */ ...
  FROM (SELECT /*+ QB_NAME(dt2) */ ... FROM ...) dt2) dt1 ...

The assigned name can then be used to refer to the query block in optimizer hints, for example:

The scope of a query block name is the whole statement. It is invalid to use the same name for multiple query blocks. You can refer to the query block "down into subquery", "down into derived table", "up to the parent" and "to a right sibling in the UNION". You cannot refer "to a left sibling in a UNION".

Limitations

Query block names declared inside view definitions (CREATE VIEW ...) are only visible inside the view. They are not accessible from outside the view.

Explicit Query Block Names With Path

circle-info

Available from MariaDB 13.0.

QB_NAME(query_block_name, query_block_path) hint is used to assign names to query blocks nested within views, derived tables, and CTEs

Syntax

where

query_block_path is similar to a path in filesystem in some sense. Each next element descends further into the query blocks structure. Path elements are separated with dots (.).

Each path element can be one of:

  • View/derived table/CTE name.

  • Select number in the current query block, such as @SEL_1, @SEL_2, etc.

  • Combination of view/derived table/CTE name and select number, such as v1@SEL_1, dt1@SEL_2, etc.

Examples

Path consisting of two elements:

Views and derived tables may be nested on multiple levels, for example:

Limitations

  • Only SELECT statements support QB names with path. DML operations (UPDATE, DELETE, INSERT) do not support them

  • QB names with path are not supported inside view definitions (CREATE VIEW ...)

Implicit Names Based on Position

circle-info

Available from MariaDB 12.2.

Besides the given name, any query block has an implicit name select_#n (where #n stands for a number). You can see these numbers in the column id of the EXPLAIN output:

Limitations

  • The positional numbers of query blocks are not stable and can change if the query is modified or its execution plan changes (for example, due to statistics re-collection). If a more stable query block addressing is needed then explicit naming is probably a better choice.

  • Implicit names based on position are not supported inside view definitions (CREATE VIEW ...).

Implicit Names Based on Aliases

circle-info

Available from MariaDB 13.0

It is possible to address a query block corresponding to a derived table, view or CTE using its name or an alias in the query.

Examples

Limitations

  • Only SELECT statements support implicit QB names based on aliases. DML operations (UPDATE, DELETE, INSERT) do not support them.

  • Implicit names based on aliases are not supported inside view definitions (CREATE VIEW ...).

Last updated

Was this helpful?