diff options
author | Sergey Petrunya <psergey@askmonty.org> | 2014-04-12 01:01:32 +0400 |
---|---|---|
committer | Sergey Petrunya <psergey@askmonty.org> | 2014-04-12 01:01:32 +0400 |
commit | 244d4b532a1f0dc103192ec6f6990056124ee93d (patch) | |
tree | 947d776cb7b67b07f4db976a37c2b6e2a0d2e9d5 /mysql-test/t/subselect_innodb.test | |
parent | 2bbca99018422b80306443a93f524a2d58373ecd (diff) | |
download | mariadb-git-244d4b532a1f0dc103192ec6f6990056124ee93d.tar.gz |
MDEV-6081: ORDER BY+ref(const): selectivity is very incorrect (MySQL Bug#14338686)
Add a testcase and backport this fix:
Bug#14338686: MYSQL IS GENERATING DIFFERENT AND SLOWER
(IN NEWER VERSIONS) EXECUTION PLAN
PROBLEM:
While checking for an index to sort for the order by clause
in this query
"SELECT datestamp FROM contractStatusHistory WHERE
contract_id = contracts.id ORDER BY datestamp asc limit 1;"
we do not calculate the number of rows to be examined correctly.
As a result we choose index 'idx_contractStatusHistory_datestamp'
defined on the 'datestamp' field, rather than choosing index
'contract_id'. And hence the lower performance.
ANALYSIS:
While checking if an index is present to give the records in
sorted order(datestamp), we consider the selectivity of the
'ref_key'(contract_id here) using 'table->quick_condition_rows'.
'ref_key' here can be an index from 'REF_ACCESS' or from 'RANGE'.
As this is a 'REF_ACCESS', 'table->quick_condition_rows' is not
set to the actual value which is 2. Instead is set to the number
of tuples present in the table indicating that every row that
is selected would be satisfying the condition present in the query.
Hence, the selectivity becomes 1 even when we choose the index
on the order by column instead of the join_condition.
But, in reality as only 2 rows satisy the condition, we need to
examine half of the entire data set to get one tuple when we
choose index on the order by column.
Had we chosen the 'REF_ACCESS' we would have examined only 2 tuples.
Hence the delay in executing the query specified.
FIX:
While calculating the selectivity of the ref_key:
For REF_ACCESS consider quick_rows[ref_key] if range
optimizer has an estimate for this key. Else consider
'rec_per_key' statistic.
For RANGE ACCESS consider 'table->quick_condition_rows'.
Diffstat (limited to 'mysql-test/t/subselect_innodb.test')
-rw-r--r-- | mysql-test/t/subselect_innodb.test | 23 |
1 files changed, 22 insertions, 1 deletions
diff --git a/mysql-test/t/subselect_innodb.test b/mysql-test/t/subselect_innodb.test index e6883d51332..af6ec90ba74 100644 --- a/mysql-test/t/subselect_innodb.test +++ b/mysql-test/t/subselect_innodb.test @@ -513,5 +513,26 @@ explain select ORDER BY t2.id ASC LIMIT 1) from t1; -drop table t1, t2; + +--echo # +--echo # MDEV-6081: ORDER BY+ref(const): selectivity is very incorrect (MySQL Bug#14338686) +--echo # + +alter table t2 add key2 int; +update t2 set key2=key1; +alter table t2 add key(key2); +analyze table t2; +flush tables; +--echo # Table tsubq must use 'ref' + Using filesort (not 'index' w/o filesort) +--replace_column 9 # +explain select + (SELECT + concat(id, '-', key1, '-', col1) + FROM t2 + WHERE t2.key1 = t1.a + ORDER BY t2.key2 ASC LIMIT 1) +from + t1; + +drop table t1,t2; |