From 81058259c7055f77dad4bca315bf4233e408ab6f Mon Sep 17 00:00:00 2001 From: Chaithra Gopalareddy Date: Wed, 18 Apr 2012 11:25:01 +0530 Subject: [PATCH] Bug#12713907:STRANGE OPTIMIZE & WRONG RESULT UNDER ORDER BY COUNT(*) LIMIT. PROBLEM: With respect to problem in the bug description, we exhibit different behaviors for the two tables presented, because innodb statistics (rec_per_key in this case) are updated for the first table and not so for the second one. As a result the query plan gets changed in test_if_skip_sort_order to use 'index' scan. Hence the difference in the explain output. (NOTE: We can reproduce the problem with first table by reducing the number of tuples and changing the table structure) The varied output w.r.t the query on the second table is because of the result in the query plan change. When a query plan is changed to use 'index' scan, after the call to test_if_skip_sort_order, we set keyread to TRUE immedietly. If for some reason we drop this index scan for a filesort later on, we fetch only the keys not the entire tuple. As a result we would see junk values in the result set. Following is the code flow: Call test_if_skip_sort_order -Choose an index to give sorted output -If this is a covering index, set_keyread to TRUE -Set the scan to INDEX scan Call test_if_skip_sort_order second time -Index is not chosen (note that we do not pass the actual limit value second time. Hence we do not choose index scan second time which in itself is a bug fixed in 5.6 with WL#5558) -goto filesort Call filesort -Create quick range on a different index -Since keyread is set to TRUE, we fetch only the columns of the index -results in the required columns are not fetched FIX: Remove the call to set_keyread(TRUE) from test_if_skip_sort_order. The access function which is 'join_read_first' or 'join_read_last' calls set_keyread anyways. --- mysql-test/r/func_group_innodb.result | 40 ++++++++++++++++++++++++ mysql-test/t/func_group_innodb.test | 44 +++++++++++++++++++++++++++ sql/sql_select.cc | 2 -- 3 files changed, 84 insertions(+), 2 deletions(-) diff --git a/mysql-test/r/func_group_innodb.result b/mysql-test/r/func_group_innodb.result index 908e85c1652..e68242a8191 100644 --- a/mysql-test/r/func_group_innodb.result +++ b/mysql-test/r/func_group_innodb.result @@ -145,3 +145,43 @@ select count(*), min(7), max(7) from t2m, t1i; count(*) min(7) max(7) 0 NULL NULL drop table t1m, t1i, t2m, t2i; +# +# Bug#12713907: STRANGE OPTIMIZE & WRONG RESULT UNDER ORDER BY +# COUNT(*) LIMIT. +# +CREATE TABLE t1 ( +id BIGINT(20) , +member_id_to INT(11) , +r_date DATE , +PRIMARY KEY (id,r_date), +KEY r_date_idx (r_date), +KEY t1_idx01 (member_id_to) +) ENGINE=InnoDB; +INSERT INTO t1 VALUES +(107924526,518491,'2011-05-01'), +(107924527,518491,'2011-05-01'), +(107924528,518491,'2011-05-01'), +(107924529,518491,'2011-05-01'), +(107924530,518491,'2011-05-01'), +(107924531,518491,'2011-05-01'), +(107924532,518491,'2011-05-01'), +(107924534,518491,'2011-06-21'), +(107924535,518491,'2011-06-21'), +(107924536,518491,'2011-06-21'), +(107924537,518491,'2011-06-21'), +(107924538,518491,'2011-06-21'), +(107924542,1601319,'2011-06-21'), +(107924543,1601319,'2011-06-21'), +(107924544,1601319,'2011-06-21'), +(107924545,1601319,'2011-06-21'), +(107924546,1601319,'2011-06-21'), +(107924547,1601319,'2011-06-21'), +(107924548,1601319,'2011-06-21'), +(107924549,1601319,'2011-06-21'), +(107924550,1601319,'2011-06-21'); +SELECT member_id_to, COUNT(*) FROM t1 WHERE r_date = +'2011-06-21' GROUP BY member_id_to ORDER BY 2 LIMIT 1; +member_id_to COUNT(*) +518491 5 +DROP TABLE t1; +# End of test BUG#12713907 diff --git a/mysql-test/t/func_group_innodb.test b/mysql-test/t/func_group_innodb.test index 1bdfd8f54bb..58f365bb244 100644 --- a/mysql-test/t/func_group_innodb.test +++ b/mysql-test/t/func_group_innodb.test @@ -83,3 +83,47 @@ explain select count(*), min(7), max(7) from t2m, t1i; select count(*), min(7), max(7) from t2m, t1i; drop table t1m, t1i, t2m, t2i; + +--echo # +--echo # Bug#12713907: STRANGE OPTIMIZE & WRONG RESULT UNDER ORDER BY +--echo # COUNT(*) LIMIT. +--echo # + +CREATE TABLE t1 ( +id BIGINT(20) , +member_id_to INT(11) , +r_date DATE , +PRIMARY KEY (id,r_date), +KEY r_date_idx (r_date), +KEY t1_idx01 (member_id_to) +) ENGINE=InnoDB; + +INSERT INTO t1 VALUES +(107924526,518491,'2011-05-01'), +(107924527,518491,'2011-05-01'), +(107924528,518491,'2011-05-01'), +(107924529,518491,'2011-05-01'), +(107924530,518491,'2011-05-01'), +(107924531,518491,'2011-05-01'), +(107924532,518491,'2011-05-01'), +(107924534,518491,'2011-06-21'), +(107924535,518491,'2011-06-21'), +(107924536,518491,'2011-06-21'), +(107924537,518491,'2011-06-21'), +(107924538,518491,'2011-06-21'), +(107924542,1601319,'2011-06-21'), +(107924543,1601319,'2011-06-21'), +(107924544,1601319,'2011-06-21'), +(107924545,1601319,'2011-06-21'), +(107924546,1601319,'2011-06-21'), +(107924547,1601319,'2011-06-21'), +(107924548,1601319,'2011-06-21'), +(107924549,1601319,'2011-06-21'), +(107924550,1601319,'2011-06-21'); + +SELECT member_id_to, COUNT(*) FROM t1 WHERE r_date = + '2011-06-21' GROUP BY member_id_to ORDER BY 2 LIMIT 1; + +DROP TABLE t1; + +--echo # End of test BUG#12713907 diff --git a/sql/sql_select.cc b/sql/sql_select.cc index 5f1efabfc97..1c5f4f5a648 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -13820,8 +13820,6 @@ check_reverse_order: join_read_first:join_read_last; tab->type=JT_NEXT; // Read with index_first(), index_next() - if (table->covering_keys.is_set(best_key)) - table->set_keyread(TRUE); table->file->ha_index_or_rnd_end(); if (tab->join->select_options & SELECT_DESCRIBE) {