Bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting

WHERE is present.

If a DELETE statement with ORDER BY and LIMIT contains a WHERE clause
with conditions that for sure cannot be used for index access (like in
WHERE @var:= field) the execution always follows the filesort path.    
It happens currently even when for the above case there is an index that
can be used to speedup sorting by the order by list.

Now if a DELETE statement with ORDER BY and LIMIT contains such WHERE
clause conditions that cannot be used to build any quick select then
the mysql_delete() tries to use an index like there is no WHERE clause at all.


mysql-test/t/delete.test:
  Added a test case for bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting
  WHERE is present.
mysql-test/r/delete.result:
  Added a test case for bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting WHERE is present.
sql/sql_delete.cc:
  Bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting WHERE is present.
  Now if a DELETE statement with ORDER BY and LIMIT contains such WHERE
  clause conditions that cannot be used to build any quick select then
  the mysql_delete() tries to use an index like there is no WHERE clause at all.

1 files changed, 1 insertions, 1 deletions

diff --git a/sql/sql_delete.cc b/sql/sql_delete.cc
index 1b00539ed71..b84b2f7eef4 100644
--- a/sql/sql_delete.cc
+++ b/sql/sql_delete.cc
@@ -142,7 +142,7 @@ int mysql_delete(THD *thd, TABLE_LIST *table_list, COND *conds,
       DBUG_RETURN(-1);			// This will force out message
     }
     
-    if (!select && limit != HA_POS_ERROR)
+    if ((!select || table->quick_keys.is_clear_all()) && limit != HA_POS_ERROR)
       usable_index= get_index_for_order(table, (ORDER*)(order->first), limit);
 
     if (usable_index == MAX_KEY)