WL#8017: Infrastructure for Optimizer Hints

Affects: Server-5.7   —   Status: Complete

In order to implement optimizer hints (WL#3996), some general infrastructure
common to all hints are needed.  Such infrastructure includes:

- A data structure for associating hints with relevant query block during parsing
- Utility functions for resolving names of database objects (e.g. table names, 
  index names) and associate hints with actual database objects (e.g., table 
  object)
- A data structure for optimizer to look up hints on current query


Some key ideas:

1. Comment syntax will be used for new hints.

   The syntax will be /*+ */

2. Multiple hints may be specified in the same comment. E.g., 

   /*+ HINT1(...) HINT2 HINT3(...) */

3. A statement block can have only one comment containing hints, and
   that comment must follow the SELECT, UPDATE, INSERT, REPLACE, or
   DELETE keyword.

4. Hints specified in the query block affect only current query block
   if QB_NAME is not specified. If QB NAME is specified for the hint,
   this hint affects query block with appropriate query block name.
   QB_NAME can not be used in views.  

5. Bad syntax in a hint will cause a warning.

6. The first of conflicting hints will have effect, subsequent
   conflicting/duplicating hints are ignored with warning.

7. Hints in views are not supported. Access to view's objects
   can be done only via system identifiers. System identifiers
   should be visible in EXPLAIN FORMAT=JSON.
   We already have query block identifier('select_id' field).
   Table identifier should be added('table_id' field).It displays
   table number in the query block(TABLE_LIST::m_tableno). Note
   that m_tableno = 0  for the first table.
   Note: Will be implemented in separate WL.

8. Naming convention for system identifiers.
   Query block system identifier could be determined
   using 'SEL#' prefix. Table identifier uses prefix 'TAB#'.

   Examples of notations:

   SEL#1 - first query block.
   TAB#0 - first table in the query block.
   TAB#0@SEL#1 - first table in the first query block.
   Note: Will be implemented in separate WL.

9. All existing hint-like things are merged with new hints. In case of
   duplication or conflict hints in old style are ignored with warning.

   MySQL already supports some hints(USE|FORCE|IGNORE INDEX).
   They should comply with new style hints.

   For example,
   /*+ NO_INDEX(t1 idx1) */ ... FROM t1 USE INDEX (idx1);

   Hints above are conflicting and hints in old style should be
   ignored with warning. There won't be any change of the old
   style hints processing. We just add verification procedure
   of the result of old style hint processing and new style hints.

   For example, for INDEX hints it's TABLE_LIST::process_index_hints()
   procedure. This procedure sets various key maps according to
   old style hints. New procedure which verifies populated key maps
   with new style hints could be added there.
   Note: Will be implemented in separate WL.


10. Hints always have higher priority against system variables.

11. Multilevel hints are supported for TABLE level.

    For instance, BKA/NO_BKA hint:

    SELECT /*+ BKA() */ * FROM t1, t2 ...; //syntax is supported
    SELECT /*+ BKA(t1) BKA(t2) */ * FROM t1, t2 ...; //syntax is supported
    SELECT /*+ BKA(t1, t2) */ * FROM t1, t2 ...; //syntax is supported

Parser for HINTs:

We will use version4 from WL#8016 Parser for optimizer hints.
(see WL#8016 for details).