Skip to content
  • Sreeharsha Ramanavarapu's avatar
    edef151b
    Bug #21749123: SELECT DISTINCT, WRONG RESULTS COMBINED WITH · edef151b
    Sreeharsha Ramanavarapu authored
                   USE_INDEX_EXTENSIONS=OFF
    
    Issue:
    ------
    CREATE TABLE testtable (
     fielda INTEGER NOT NULL,
     fieldb INTEGER NOT NULL,
     fieldc INTEGER NOT NULL,
     PRIMARY KEY (fielda,fieldb),
     KEY fieldb_idx (fieldb)
    ) ENGINE=Innodb;
    
    SELECT DISTINCT fieldb
    FROM testtable
    WHERE fielda IN (...) AND fieldb IN (...);
    
    With index extensions turned off, fielda shouldn't be used
    as part of fieldb_idx. So when the query tries to use loose
    index scan on fieldb_idx, the corresponding range tree for
    the lookup doesn't contain fielda. Since this approach
    involves a lookup of the index fieldb_idx, we get a wrong
    result.
    
    Solution:
    ---------
    Loose index scan is the wrong choice for this query given
    that fielda is not covered by fieldb_idx when
    index_extensions is turned off.
    
    Each field has a flag, part_of_key_not_clustered which
    tracks the indexes that cover the field. When index
    extensions is turned off, this flag can be used to track
    whether a particular field is part of the secondary index
    or is part of the primary key that has been appended by the
    storage engine..
    edef151b
    Bug #21749123: SELECT DISTINCT, WRONG RESULTS COMBINED WITH
    Sreeharsha Ramanavarapu authored
                   USE_INDEX_EXTENSIONS=OFF
    
    Issue:
    ------
    CREATE TABLE testtable (
     fielda INTEGER NOT NULL,
     fieldb INTEGER NOT NULL,
     fieldc INTEGER NOT NULL,
     PRIMARY KEY (fielda,fieldb),
     KEY fieldb_idx (fieldb)
    ) ENGINE=Innodb;
    
    SELECT DISTINCT fieldb
    FROM testtable
    WHERE fielda IN (...) AND fieldb IN (...);
    
    With index extensions turned off, fielda shouldn't be used
    as part of fieldb_idx. So when the query tries to use loose
    index scan on fieldb_idx, the corresponding range tree for
    the lookup doesn't contain fielda. Since this approach
    involves a lookup of the index fieldb_idx, we get a wrong
    result.
    
    Solution:
    ---------
    Loose index scan is the wrong choice for this query given
    that fielda is not covered by fieldb_idx when
    index_extensions is turned off.
    
    Each field has a flag, part_of_key_not_clustered which
    tracks the indexes that cover the field. When index
    extensions is turned off, this flag can be used to track
    whether a particular field is part of the secondary index
    or is part of the primary key that has been appended by the
    storage engine..
Loading