SQL замедление 'ORDER BY'

ORDER BY не является обычно медленным, при условии, что база данных может найти индекс, который соответствует ORDER BY выражение.

Однако Ваш SQL-оператор мог бы включать другие вещи, которые вынуждают базу данных просканировать всю таблицу прежде, чем возвратить результаты, как SELECT TOP n

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

Абсолютно необходимо использовать вид SQL, а не вид кода, если это возможно, таким образом, Вы на правильном пути там.

ОБНОВЛЕНИЕ: хорошо, несколько вещей. Во-первых, Вы не должны использовать "+loadedModuleName +" конструкция, поскольку она делает каждый запрос уникальным и завинчивает оптимизатор. Используйте параметр. Во-вторых, Ваш Порядок пунктом неоднозначен относительно того, является ли это таблицей A, или B - делают это явным и выбирают таблицу с Индексом (даже если у обоих есть индексы, сделайте его явным). Наконец, Ваше поле "Previous" может все еще быть индексировано как раз когда символ (1). Я сделал бы все кроме последнего предложенного индекса, тестовой скорости и, если все еще медленный, пойти для индекса и проверки снова.

ОБНОВИТЕ, Таким образом, Вы будете возвращать <1 000 записей, но каков размер таблицы всего?

ОБНОВИТЕ, О, человек, я сожалею, что не поймал это прежде. Если Вы хотите развернуть его правильно на SQL Server, Ваш запрос должен быть:

SELECT A.NAME, B.SYNTAX, B.DESCRIPTION, A.RATE1, A.RATE2, A.RATE3, A.STARTDATE, A.ENDDATE, A.HIDE, A.CATEGORYNAME 
FROM Table1 A join Table2 B on (A.Name=B.Name)
WHERE (A.MODULENAME=@ModuleName) AND (A.PREVIOUS<>'N' OR A.PREVIOUS IS NULL) 
ORDER BY A.NAME

Попробуйте это, и я почти гарантирую, что Вы будете видеть огромное ускорение.

Если Ваш фильтр похож на это:

WHERE col1 = @value1
      AND col2 = @value2
      AND col3 = @value3
ORDER BY
      col4

, затем необходимо будет создать индекс на (col1, col2, col3, col4).

Оптимизатор будет использовать индекс и чтобы отфильтровать на первых трех значениях и заказать четвертым.

Если у Вас не будет такого индекса, то одно из следующего произойдет:

1. Оптимизатор будет использовать индекс на отфильтровать на WHERE условие, но это будет все еще иметь к ORDER оставление строками.
2. Оптимизатор будет использовать индекс для ORDER значения, но ВСЕ значения должны будут быть рассмотрены для фильтрования их.
3. Оптимизатор не будет использовать индекс вообще, таким образом, оба недостатков от 2 "ВСЕХ значений должны будут быть рассмотрены для фильтрования их", и 1 "вся остающаяся строка должна быть заказана", верны.

ОБНОВЛЕНИЕ: Как запрос, который Вы отправили, я думаю, что наилучший вариант состоит в том, чтобы рассмотреть запрос как хороший потому что:

• Для немногих строк не заботьтесь о том, кто делает работу. Затем более легким для Вас является использование ORDER BY.
• Для большого количества строк не уезжайте, клиент делают работу: RDMBS, которые это больше специализировало и уверенный сервер, имеют больше памяти и ЦП.

Подсказки для заказов, которые необходимо рассмотреть:

• ORDER BY ЕДИНСТВЕННЫЙ путь к гарантийному виду на SQL-запросе.
• Лучший рабочий на сортировке является базой данных в любом случае: УБЕДИТЕСЬ В ЭТОМ!
• Попытайтесь минимизировать кардинальность для возвращенных строк.
• Создайте индексы согласно запросу. Это означает, помещает заказанные столбцы в последний раз на индекс.
• Постарайтесь не индексировать, если запрос быстр.
• Можно полагать, что индексы отсортированы, затем если Вы сортируете только для таблицы и имеете хорошие индексы, вид мог стоить близкого нуля.

Поскольку больше эмпирических правил об индексах ищет это другой ТАК вопрос.

ORDER BY не является особенно медленным, особенно если существует индекс на том столбце. В частности, если у Вас есть кластерный индекс на том столбце, данные уже отсортированы.

Можно также использовать подкачку страниц (TOP или ROW_NUMBER) и т.д. помочь.

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

Добавление ORDER BY вынудит это ожидать на базе данных всех результатов, которые покажут реальную скорость запроса.

В тех случаях исходный запрос и ЗАКАЗАННЫЙ являются той же скоростью; Вы просто дурачились, заставляя думать, первый был быстр, потому что Ваш редактор был быстр для получения главных приблизительно 50 строк.

При выборе небольшого количества достаточно строк для отображения, не возможно что ORDER BY пункт занял бы любое заметное количество времени, если Вы не ограничиваете количество строк, возвращенных с LIMIT или TOP.

Нам нужно больше информации. Какая DBMS? На что похож план запросов? Вы посмотрели на планы запросов с и без ORDER BY? Какие различия Вы видите?

Править:

SELECT A.NAME, B.SYNTAX, B.DESCRIPTION, A.RATE1, A.RATE2,  
A.RATE3, A.STARTDATE, A.ENDDATE, A.HIDE, A.CATEGORYNAME  
FROM A, B  
WHERE A.MODULENAME='"+loadedModuleName+"'   
  AND A.NAME = B.NAME  
  AND (A.PREVIOUS<>'N' OR A.PREVIOUS IS NULL)  
ORDER BY NAME

NAME primary key? Есть ли index на NAME? Отдельно, или с другими полями? В какой последовательность?
Сколько строк возвращается для одного loadedModuleName?
Я подозреваю, что замедление прибывает из"A.PREVIOUS <> 'N' OR A.PREVIOUS IS NULL" Попытайтесь использовать (NOT A.PREVIOUS = 'N') то, которое я думаю, эквивалентно и может помочь немного.
Время запрос с и без ORDER BY и посмотрите, отличается ли синхронизация вообще. Это не должно быть.

Если NAME не уникально в также A или B, Ваше соединение собирается пойти частично баллистическое когда каждый A.NAME экземпляр становится перекрестным присоединенным на B.NAME. Если соответствие строк на 50 А и 50 соответствий строк B, Вы закончите с 2 500 строками результата, которые не могут быть тем, что Вы предназначаете.

Это не должно быть медленно. Оптимизируйте свой запрос и структуру базы данных (по крайней мере, индексы и statistcs, если это - SQL Server). Возможно, существует некоторая другая вещь в Вашем запросе кроме ORDER BY который вызывает это замедление?

SELECT A.NAME, B.SYNTAX, B.DESCRIPTION, A.RATE1, A.RATE2, A.RATE3,
       A.STARTDATE, A.ENDDATE, A.HIDE, A.CATEGORYNAME
FROM Table1 A JOIN Table2 B on A.Name = B.Name
WHERE A.MODULENAME = @ModuleName AND A.PREVIOUS<>'N' OR A.PREVIOUS IS NULL
ORDER BY A.NAME

Опция 1

Если Вы - quering всего несколько простых столбцов (2-4), можно включать их в индекс также. Таким образом, Ваш запрос будет, работал быстрее. Также удостоверьтесь, что порядок сортировки на том столбце индекса соответствует порядку сортировки в Вашем запросе.

// if your query looks like this:
SELECT [Name], [Title], [Count] ORDER BY [COUNT]

// you can create an index on [Name], [Title], [Count]

Опция 3

Создайте a view и свяжите его с schema. Затем запросите данные из этого view.

Опция 3

Если Вы используете SQL Server 2005 и obove, можно также попытаться выполнить Вас запрос в SQL Server Profiler, и он рекомендует Вам лучший индекс и статистику, которая можно обратиться таблице для оптимизации производительности этого конкретного запроса.

Опция 4

Попытайтесь восстановить свои индексы и статистику.

Опция 5

Можно попытаться поместить Вас индекс/таблица в отдельную группу файлов на другом жестком диске.

Это не справедливый оператор, чтобы сказать, что "порядок" является медленным в и себя. У Вас есть многие RDBM's для рассмотрения до их собственной реализации, и схемы индексации и типа данных. Я, однако, сомневался бы, что можно отсортировать его быстрее клиентский, чем Вы можете на сервере, но это не должно говорить, что сортировка его на сервере является правильным поступком.

Существует много проблем в действии здесь.

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

К сожалению, на практике база данных часто становится узким местом для приложения. Что-либо, что можно сделать для отодвигания работы от базы данных, улучшит полную пропускную способность приложения. Это включает движущиеся операции вида в менее - занятый бизнес, сеть или уровень представления. Уровень представления не может сортировать один запрос как эффективно, но он мог бы иметь больше возможностей для обработки той полной нагрузки. Это особенно верно, когда можно надежно продвинуть ту работу полностью к машинам отдельного конечного пользователя, хотя это может быть проблематично.

С другой стороны, существует больше для рассмотрения здесь, чем чистая производительность. Вы также хотите думать о будущем обслуживании. Что более удобно в сопровождении, чем простой пункт "ORDER BY"? Это - только одна строка кода, по сравнению с тем, кто знает сколько дополнительной работы программиста получать вид, работающий в другом месте. Это могло бы быть случаем, где Вы - более обеспеченный бросок небольшого количества денег в проблеме, чтобы удостовериться, что Ваша база данных просто может поддержать допустимый уровень производительности, видов и так далее.

Даже здесь проблема не сокращается и не сушеная. Существует философская школа, которая полагает, что сортировку действительно нужно считать функцией уровня представления так или иначе, и что в конечном счете уровень представления является также более удобным в сопровождении местом, чтобы сделать эту работу. Я не подписываюсь на ту теорию, но это там.

ORDER BY вызывает RDBMS к виду.

Сортировка требует ресурсов, которые не могут присутствовать на Вашем сервере RDBMS.

В некоторых случаях (т.е. запросы единственной таблицы) можно записать ORDER BY, который соответствует индексам - и если RDBMS гарантирует, что таблицы сохранены в индексном порядке - это могла бы быть нулевая стоимость. [Дизайн DB, который зависит от большого количества запросов единственной таблицы, может быть улучшен еще больше путем отбрасывания RDBMS и использования файлов.]

Обычно ORDER BY оказывается перед необходимостью вид.

"Я полагал, что получение базы данных сделать это для меня является самым эффективным".

То предположение является дефектным. База данных не обязательно более эффективна, чем Ваша программа вне базы данных.

При сортировке на клиенте, по-моему, что-то, что Вы не должны делать. Механизмы базы данных оптимизированы для сортировки данных.

Как сказанные другие, если можно ограничить количество строк, Вы выбираете, это будет работать быстрее.

Ответ на следующие вопросы мог помочь пойти далее:

• Сколько строк возвращается запросом?
• Сколько столбцов выбирается?
• Вы присоединяетесь к каким-либо таблицам?
• Сколько времени занимает с / без ORDER BY?

Существует тонна действительно хороших предложений здесь, но существует одна незначительная вещь, я не вижу, что хотел бы прокомментировать.

Какую базу данных Вы используете? Как кто-то, кто тратит тонну времени на MySQL вещь, которая выскакивает во мне, ИЛИ оператор. MySQL может быть действительно глупым с ORs. Я видел, что это быть быстрее, чтобы сделать два выбирает и ОБЪЕДИНЕНИЕ их вместе.

Если Ваше количество строки является большим (в таблице, не возвращенной), который мог бы быть фактором.

Иначе я согласился бы с другими сообщениями. Индексы должны сделать его быстро, и часто лучше позволить DB сделать это, а не обработать его самостоятельно. DB знает то, что он делает. Если Вам не установили ДЕЙСТВИТЕЛЬНО большие данные и хотите сместить нагрузку сортировки для клиента (таким образом, DB может взять больше запросов), я позволил DB сделать работу сортировки.