Почему SELECT * бывают на величины быстрее, чем SELECT foo?

Рассмотрим таблицу значений и хэши, например, так:

+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| val        | char(9)  | NO   |     | NULL    |                |
| val_hashed | char(50) | YES  |     | NULL    |                |
+------------+----------+------+-----+---------+----------------+

Следующий запрос завершается через 0,00 секунды:

SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;

Однако этот запрос занимает 3 минуты 17 секунд:

SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1;

Я вижу, что во время выполнения запроса список процессов показывает его как статус Sorting result. Ситуация полностью воспроизводима. Обратите внимание, что существует другой процесс, выполняющий INSERTоперации над таблицей непрерывно.

Почему более конкретный запрос выполняется дольше, чем *запрос? Я всегда считал, что *следует избегать запросов специально по соображениям производительности.

Фраза ORDER BY 1относится к различным столбцам; в первом это будет id, во втором val. Так idкак это ключ, он будет проиндексирован, и это order byбудет тривиальный объем работы. Чтобы order by val, однако, система будет извлекать каждую строку, сортировать полную таблицу по val, а затем выбрать только одну из этих строк.

Измените оба запроса на, order by idи я думаю, что ваше время выполнения будет почти одинаковым.

Разница в производительности в вашем запросе хорошо объяснена MG. Я собираюсь обратиться к этому:

Я всегда считал, что * запросов следует избегать специально по соображениям производительности.

select *Сам по себе не несет особых штрафных санкций, это проблематично при неправильном использовании. В запросе с одной таблицей это работает просто отлично. Теперь присоедините эту таблицу к другой с 20 столбцами, а затем добавьте объединения к 5 другим таблицам с множеством столбцов в каждой. СЕЙЧАС это проблема. Так же как и люди, которые преподают широкую ленточную помощь «никогда не делай Х», не объясняя почему.