fix for one of the bugs spotted by #1274
sql/sql_select.cc: back to the bug #1274: the following query EXPLAIN SELECT SQL_CALC_FOUND_ROWS race_name FROM races WHERE race_name LIKE '%Madison%' ORDER BY race_date DESC LIMIT 0,100 +-------+------+---------------+------+---------+------+--------+-----------------------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +-------+------+---------------+------+---------+------+--------+-----------------------------+ | races | ALL | NULL | NULL | NULL | NULL | 505821 | Using where; Using filesort | +-------+------+---------------+------+---------+------+--------+-----------------------------+ The query returns no rows. There are two problems with it: - wrong access plan is chosed (sequential index scan in reverse order, which is VERY SLOW in case of MyISAM table + packed keys) It's wrong, because it doesn't take into account that SQL_CALC_FOUND_ROWS is present, in other words, is based on assumtion that LIMIT clause decrease number of rows to access significantly, which is not true as all rows are accessed. - the access plan is not shown in the EXPLAIN (bug #1560). I'm not fixing it here
Showing
Please register or sign in to comment