Home/ Questions/Q 297567
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T06:39:05+00:00

This a follow-up to a previous question . How can I optimize this query

  • 0

This a follow-up to a previous question.

How can I optimize this query so that it does not perform a full table scan?

 SELECT Employee.name FROM Employee WHERE Employee.id <> 1000;

.

explain SELECT Employee.name FROM Employee WHERE Employee.id <> 1000;
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table       | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | Employee    | ALL  | PRIMARY       | NULL | NULL    | NULL | 5000 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+

(Empoyee.id is the primary key, in case that isn’t clear.)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Have a covering index for name and id, and it should be able to fulfill the query using the index. This might be faster, because there’s a good chance the entire index will already be in memory, while a table scan is more likely to need to go to disk.

    Because of the low (non-existent) selectivity of your where clause you may need to provide a hint to get the database to use your index. I’m a sql server guy, and so I’m not sure of the syntax needed in mysql to hint an index, or even if mysql is able to take advantage of a covering index in this manner.

    That said, I doubt you can get much improvement: you’re returning every row but one. You should expect that to need to scan the table.

    • 0