Как оптимизировать этот запрос? - PullRequest
Новая
       6

Как оптимизировать этот запрос?

0 голосов
/ 22 октября 2009

Запрос: 

select id,
       title 
  from posts 
 where id in (23,24,60,19,21,32,43,49,9,11,17,34,37,39,46,5
2,55)

Объяснить план: 

mysql> explain select id,title from posts where id in (23,24,60,19,21,32,43,49,9,11,17,34,37,39,46,5
2,55);
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | posts | ALL  | PRIMARY       | NULL | NULL    | NULL |   30 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.05 sec)

id - это первичный ключ таблицы сообщений.

Ответы [ 2 ]

3 голосов
/ 22 октября 2009

За исключением добавления других индексов, таких как

  • идентификатор кластеризованного индекса
  • индекс покрытия, который включает id [first] и другие столбцы из предложения SELECT

похоже, мало что можно сделать ...

На самом деле, даже если бы были доступны такие индексы, MySQL может решить выполнить сканирование таблицы , как здесь (тип «ВСЕ»). Причиной может быть в таблице может быть относительно небольшое количество строк (по сравнению с предполагаемым числом строк, которое должен вернуть запрос) , и поэтому более эффективно последовательно «читать» таблицу, отбрасывая несоответствие строки, как мы идем, а не "надеясь повсюду", с косвенным указателем индекса.

0 голосов
/ 22 октября 2009

Я не вижу никаких проблем с этим. Если вам нужно выбрать из списка, то «IN» является правильным способом сделать это. Вы не выбираете ненужную информацию, и то, что вы выбираете, является ключом, который предположительно проиндексирован.

...