MIN/MAX против ORDER BY и LIMIT

Ответ 1

В худшем случае, когда вы смотрите на неиндексированное поле, для использования MIN() требуется один полный проход таблицы. Использование SORT и LIMIT требует файлового управления. Если работать с большой таблицей, вероятно, будет значительная разница в производительности. В качестве бессмысленной точки данных MIN() взяла 0,36 с, а SORT и LIMIT взяла 0,84 с таблицы 106 000 строк на моем dev-сервере.

Если, однако, вы смотрите на индексированный столбец, разница становится сложнее заметить (бессмысленная точка данных равна 0,00 с в обоих случаях). Однако, глядя на результат объяснения, похоже, что MIN() может просто вырезать наименьшее значение из индекса ( "Выбрать таблицы оптимизированы" и "NULL" ), тогда как SORT и LIMIT по-прежнему необходимо выполнить упорядоченный обход индекса (106 000 строк). Фактическое влияние на производительность, вероятно, незначительно.

Похоже, что MIN() - это способ пойти - он быстрее в худшем случае, неотличимый в лучшем случае, является стандартным SQL и наиболее четко выражает ценность, которую вы пытаетесь получить. Единственный случай, когда кажется, что использование SORT и LIMIT было бы желательным, было указано в mson, где вы пишете общую операцию, которая находит верхние или нижние значения N из произвольных столбцов и не стоит записывать операцию специального случая.

Ответ 2

SELECT MIN(`field`)
FROM `tbl`;

Просто потому, что он совместим с ANSI. Предел 1 относится к MySql как ТОП для SQL Server.

Ответ 3

В качестве mson и Шон Максомем отметили, что MIN предпочтительнее.

Еще одна причина, по которой ORDER BY + LIMIT полезен, - это если вы хотите получить значение другого столбца, чем столбец MIN.

Пример:

SELECT some_other_field, field
FROM tbl
ORDER BY field
LIMIT 1

Ответ 4

Я думаю, что ответы зависят от того, что вы делаете.

Если у вас есть запрос с 1 выводом и намерение выполняется так же просто, как вы указали, выберите min (поле).

Однако обычно бывает, что эти типы требований меняются в - захватывать верхние результаты, захватывать nth-mth результаты и т.д.

Я не думаю, что это слишком ужасная идея совершить вашу выбранную базу данных. Изменение dbs не должно производиться легко, и вам придется пересмотреть цену, которую вы платите, когда делаете это.

Зачем ограничивать себя сейчас, за боль, которую вы можете или не чувствуете позже?

Я считаю, что лучше оставаться ANSI как можно больше, но это всего лишь ориентир...

Ответ 5

Учитывая приемлемую производительность, я бы использовал первую, потому что она семантически ближе к намерению.
Если производительность была проблемой, (большинство современных оптимизаторов будут оптимально оптимизировать как один и тот же план запроса, хотя вам нужно проверить, чтобы проверить это), тогда, конечно, я бы использовал более быстрый.