Заказ по столбцам

Question

При добавлении дополнительных столбцов в ORDER BY снижается производительность?

ORDER BY STYLE

против

ORDER BY STYLE, SIZE, COLOR

Answer 1

Вообще-то да.Представьте себе таблицу, в которой тысячи идентичных стилей, и каждый стиль имеет много одинаковых размеров с разными цветами.Затем движок SQL должен сначала выполнить сортировку для стилей, затем для каждого стиля он должен отсортировать размеры и, наконец, цвета.Это занимает больше времени, чем сортировка стилей в одиночку.Но фактический штраф может варьироваться в зависимости от структуры таблицы, используемых индексов, разновидности сервера SQL и т. Д. Вы можете варьировать пробег.

Answer 2

При отсутствии каких-либо индексов для столбцов: No.

Предложение ORDER BY никогда не будет превращено в серию операций SORT при выполнении.При сортировке списка механизм запросов выполнит одно или несколько сравнений между строками в наборе результатов;он использует предложение ORDER BY, чтобы определить, должна ли одна строка быть до или после другой строки.Это нужно сделать только один раз.

сложность выражений в предложении ORDER BY, конечно, может повлиять на производительность (например, если одно из них включает вызов функциивыполняются некоторые дорогостоящие операции), но снижение производительности напрямую не связано с количеством столбцов сортировки как таковых.

Answer 3

Если у вас есть составной индекс для (style, size, color), и , то нет предложений WHERE, основанных на столбцах, которых также нет в индексе, вы можете заказать color бесплатно.

Если у вас есть только составной индекс (style, size), то добавление столбца color в ORDER потребует от базы данных некоторого переупорядочения, что будет немного медленнее.

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

Некоторый фон по оптимизации ORDER-BY.Детали здесь специфичны для MySQL, но общая концепция является общей для индексации в реляционных базах данных.

Answer 4

Если у вас есть индекс, который охватывает вид, который будет использоваться, то, я думаю, он не сильно изменится, если вообще будет.т.е. если у вас есть индекс, который имеет STYLE, SIZE, COLOR. Если у вас есть 3 отдельных индекса STYLE, SIZE, COLOR или нет индексов, тогда perf будет хуже, потому что он, вероятно, сможет использовать только один индекс для сортировки.Иногда, хотя SQL-сервер может не использовать индекс для плана запроса, даже если хороший существует, зависит от того, что делает остальная часть вашего запроса ...

Как узнать штраф за перфорирование .. ВСтудия SQL Management записывает оба запроса и включает планы выполнения, ищет стоимость поддерева узла слева как показатель того, какой запрос является лучшим с точки зрения затрат на машину и, следовательно, производительности.Однако результаты могут меняться в зависимости от данных (если у вас есть тестовый сервер с небольшими объемами данных, вы можете получить совсем другие планы запросов, чем для больших производственных данных)

Answer 5

Может иметь значение, которое зависит от того, какие данные вы выбираете и по каким данным вы сортируете.

Часто вообще не существует ощутимой разницы в производительности.Я только что сравнил планы выполнения двух одинаковых запросов, за исключением одного сортировки по одному полю, в то время как другие сортируют по 95 полям, и не было никакой разницы в стоимости процессора или стоимости ввода-вывода для операции сортировки.

Если я уменьшу количество выбранных полей, чтобы сортировка получала доступ к данным, которые в противном случае были бы не нужны, разница в стоимости процессора составила 1,6 процента.Это разница, но, безусловно, незначительная.

Answer 6

Да, но я не думаю, что это важно, поскольку у вас уже есть порядок по пунктам.