Skip to content
  • Sreeharsha Ramanavarapu's avatar
    aff80362
    Bug #27998526 : FORCE INDEX DOESN'T TAKE EFFECT WHEN A · aff80362
    Sreeharsha Ramanavarapu authored
                    QUERY HAS GROUP_BY, ORDER_BY, AND LIMIT
    
    Issue:
    ------
    FORCE INDEX is ignored when a query has GROUP_BY, ORDER_BY,
    AND LIMIT.
    
    This problem doesn't occur GROUP BY or ORDER BY is removed.
    
    
    DDL and Query:
    --------------
    CREATE TABLE t1 (id INT NOT NULL AUTO_INCREMENT,
                     k INT,
                     PRIMARY KEY(id),
                     KEY idx_k (k));
    
    SELECT * FROM t1 FORCE INDEX (idx_k)
      WHERE k BETWEEN 2 AND 5
      GROUP BY id
      ORDER BY id LIMIT 0,1;
    
    Root cause:
    -----------
    Due to the presence of GROUP BY optimizer adds clustered
    index to the set of possible keys
    (see add_group_and_distinct_keys()).
    
    test_if_order_by_key() then decides that "idx_k" can't
    provide ordering and that index is excluded from the list of
    potential indexes to be used by range optimizer for
    ORDER BY. Since the only other option left is the clustered
    index, that is chosen.
    
    Solution:
    ---------
    If FORCE INDEX is set use only those indexes to check if
    they are relevant for ORDER BY. In this query, range
    optimizer won't be called since there is no relevant index
    (since "idx_k" doesn't include the column "id").
    
    In 5.7, this was fixed as part of WL#6986.
    aff80362
    Bug #27998526 : FORCE INDEX DOESN'T TAKE EFFECT WHEN A
    Sreeharsha Ramanavarapu authored
                    QUERY HAS GROUP_BY, ORDER_BY, AND LIMIT
    
    Issue:
    ------
    FORCE INDEX is ignored when a query has GROUP_BY, ORDER_BY,
    AND LIMIT.
    
    This problem doesn't occur GROUP BY or ORDER BY is removed.
    
    
    DDL and Query:
    --------------
    CREATE TABLE t1 (id INT NOT NULL AUTO_INCREMENT,
                     k INT,
                     PRIMARY KEY(id),
                     KEY idx_k (k));
    
    SELECT * FROM t1 FORCE INDEX (idx_k)
      WHERE k BETWEEN 2 AND 5
      GROUP BY id
      ORDER BY id LIMIT 0,1;
    
    Root cause:
    -----------
    Due to the presence of GROUP BY optimizer adds clustered
    index to the set of possible keys
    (see add_group_and_distinct_keys()).
    
    test_if_order_by_key() then decides that "idx_k" can't
    provide ordering and that index is excluded from the list of
    potential indexes to be used by range optimizer for
    ORDER BY. Since the only other option left is the clustered
    index, that is chosen.
    
    Solution:
    ---------
    If FORCE INDEX is set use only those indexes to check if
    they are relevant for ORDER BY. In this query, range
    optimizer won't be called since there is no relevant index
    (since "idx_k" doesn't include the column "id").
    
    In 5.7, this was fixed as part of WL#6986.
Loading