Я не совсем понимаю, как команда SQL будет сортировать большой набор результатов. Это делается в памяти "на лету" (т.е. Когда выполняется запрос)?
Будет ли быстрее сортироваться с помощью ORDER BY в SQL, а не сортировать, например, связанный список объектов, содержащих результаты на языке Java (предполагая быструю встроенную сортировку, возможно, используя quicksort)?
Почти наверняка будет более эффективно сортировать данные в базе данных. Базы данных предназначены для работы с большими объемами данных. И доступны базы данных, которые недоступны для среднего уровня. Если вы планируете писать гиперэффективную процедуру сортировки в среднем уровне, которая использует информацию, которую у вас есть о ваших данных, которых нет в базе данных (т.е., обрабатывая данные в кластере из десятков компьютеров среднего уровня, чтобы сортировка никогда не разливается на диск, пользуясь тем фактом, что ваши данные в основном упорядочены, чтобы выбрать алгоритм, который обычно не был бы особенно эффективным), вы, вероятно, можете побить скорость сортировки базы данных. Но это, как правило, редко.
В зависимости от запроса, например, оптимизатор базы данных может выбрать план запроса, который возвращает данные в порядке, не выполняя сортировку. Например, база данных знает, что данные в индексе сортируются, поэтому он может выбрать сканирование индекса, чтобы вернуть данные в порядок, не прибегая к материализации и сортировке всего набора результатов. Если это необходимо для материализации всего результата, ему нужны только столбцы, которые вы сортируете, и какой-то идентификатор строки (то есть ROWID в Oracle), а не сортировка целой строки данных, таких как наивная реализация среднего уровня, скорее всего, Например, если у вас есть составной индекс (col1, col2), и вы решили сортировать по UPPER (col2), LOWER (col1), база данных может считывать значения col1 и col2 из индекса, сортировать идентификаторы строк и затем перейдите к данным из таблицы. Конечно, в базе данных этого не нужно: оптимизатор будет учитывать стоимость сортировки по сравнению с затратами на сбор данных из таблицы или из разных индексов. База данных вполне может прийти к выводу, что наиболее эффективным методом является сканирование таблицы, чтение всей строки в память и сортировка. Он может заключить, что использование индекса приводит к большему количеству ввода-вывода для извлечения данных, но компенсирует его, уменьшая или устраняя затраты на сортировку.
Ответ: это зависит. Если часть ORDER BY может быть выполнена с использованием индекса в базе данных, тогда план выполнения запроса будет использовать этот индекс, и результаты вернутся в правильном порядке прямо из БД. Если нет, то база данных будет выполнять сортировку, но, скорее всего, лучше, чем вы читаете все результаты в памяти (и, конечно, лучше, чем чтение результатов в связанном списке).
Точный метод зависит от используемого вами продукта, но обычно полнофункциональная СУБД имеет в своем распоряжении множество алгоритмов сортировки. Некоторые работают на диске, оптимизируя пространство во времени, некоторые работают в памяти, оптимизируя скорость. Проверьте исходный код доступных открытых исходных кодов, если вы заинтересованы в деталях gory.
Вряд ли вы получите лучшие результаты, выполнив сортировку самостоятельно или используя какую-либо другую библиотеку, хотя могут быть такие патологические случаи, как некоторая операционная система qsort(), имеющая проблемы с определенными распределениями данных. Попробуйте, если нужно, но предпочитайте использовать СУБД для управления вашими данными, потому что это то, на что они хороши.
Если сортировка не основана на индексе, если вы используете сортировку базы данных, вы гарантируете, что будете ожидать, что весь набор результатов будет разрешен и отсортирован в базе данных, прежде чем вы увидите даже одну строку набора результатов.
Если вы сортируете его самостоятельно, данные могут быть инкрементно потоковыми (лучше для среды с ограниченной сетью) и, возможно, поэтапно полезно для приложения, уменьшающего задержку выполнения, даже если операция сортировки потребляет одинаковое количество общего времени.
В зависимости от сценария развертывания это может иметь большое значение, когда дополнительные затраты, связанные с сортировкой, должны быть выплачены. В сценариях я работаю со средним уровнем, является одноразовым и масштабируемым, в то время как уровень данных дороже, чтобы масштабироваться. Если он стоит одного и того же процессора, но процессор ЦП стоимостью 5 или 10 раз с точки зрения эксплуатационных затрат, он становится дешевле в реальном режиме, чтобы сделать это за пределами базы данных.