-
Evgeny Potemkin authored
In order to pick best access method for a derived table optimizer creates fake keys, one per each table joined to the derived one. Fields of derived table are marked appropriately. After picking best index fields weren't unmarked and that confused ICP code and led to pushing into storage engine a condition that couldn't be used as a part of ICP. In its turn this led to a wrong result. Now TABLE::use_index remove marking from all fields that aren't used in the index picked for the derived table. To ease tracking of such bugs and show more info on automatically created keys JSON EXPLAIN now prints array of used key parts and labels it as 'used_key_parts'. The only exception is when several indexes are used for a single table (e.g. in index merge). In this case nothing is printed.
Evgeny Potemkin authoredIn order to pick best access method for a derived table optimizer creates fake keys, one per each table joined to the derived one. Fields of derived table are marked appropriately. After picking best index fields weren't unmarked and that confused ICP code and led to pushing into storage engine a condition that couldn't be used as a part of ICP. In its turn this led to a wrong result. Now TABLE::use_index remove marking from all fields that aren't used in the index picked for the derived table. To ease tracking of such bugs and show more info on automatically created keys JSON EXPLAIN now prints array of used key parts and labels it as 'used_key_parts'. The only exception is when several indexes are used for a single table (e.g. in index merge). In this case nothing is printed.
Loading