Bug #106987 | when set prefer_ordering_index=off, a very simple sql become very slow | ||
---|---|---|---|
Submitted: | 12 Apr 2022 7:30 | Modified: | 12 Apr 2022 14:09 |
Reporter: | WANG GUANGYOU | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
Version: | OS: | Any | |
Assigned to: | CPU Architecture: | Any |
[12 Apr 2022 7:30]
WANG GUANGYOU
[12 Apr 2022 10:39]
WANG GUANGYOU
i think we can decrease the chance by using the optimization when the plan is bad like full table scan or full index scan. diff --git a/sql/sql_optimizer.cc b/sql/sql_optimizer.cc index 9b34fab..27ba5f0 100644 --- a/sql/sql_optimizer.cc +++ b/sql/sql_optimizer.cc @@ -2117,7 +2117,7 @@ test_if_skip_sort_order(JOIN_TAB *tab, ORDER *order, ha_rows select_limit, force index for order/group is specified. */ if (thd->optimizer_switch_flag(OPTIMIZER_SWITCH_PREFER_ORDERING_INDEX) || - is_force_index) + is_force_index || tab->type() == JT_ALL || tab->type() == JT_INDEX_SCAN) test_if_cheaper_ordering(tab, order, table, usable_keys, ref_key_hint, select_limit,
[12 Apr 2022 14:09]
MySQL Verification Team
Hi Mr. Guangyou, Thank you for your bug report. However, it is not a bug. The optimiser_switch "prefer_ordering_index=on/off" is there to be used and set separately for each query that you have and which is using ORDER BY or GROUP BY or similar ..... Hence, you can not expect to have better results for all types of queries with the same setting of that switch. Not a bug.