Производительность функций SQL против функций кода

Question

В настоящее время мы изучаем нагрузку на наш сервер SQL и ищем способы ее снижения. Во время обучения в средней школе мне всегда говорили, что с точки зрения производительности дешевле заставить SQL Server работать. Но так ли это?

Вот пример:

SELECT ord_no FROM oelinhst_sql

Возвращает 783119 записей за 14 секунд. Поле имеет значение char(8), но все наши порядковые номера состоят из шести цифр, поэтому каждый из них содержит два пустых символа. Обычно мы обрезаем это поле, поэтому я запустил следующий тест:

SELECT LTRIM(ord_no) FROM oelinhst_sql

Это вернуло 783119 записей за 13 секунд. Я также попробовал еще один тест:

SELECT LTRIM(RTRIM(ord_no)) FROM oelinhst_sql

С правой стороны нечего обрезать, но я пытался выяснить, были ли какие-то издержки в простом акте вызова функции, но он все равно вернулся через 13 секунд.

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

Answer 1

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

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

Answer 2

Обычно это пользовательские функции (UDF), которые получают плохую оценку производительности SQL и могут быть источником ваших советов.

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

Как вы выяснили с помощью rtrim и ltrim, это не единственная причина, чтобы прекратить использование всех функций на стороне sql.

Answer 3

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

Это обычно намного быстрее

SELECT SomeFields FROM oelinhst_sql
WHERE
  datetimeField > '1/1/2011'
  and
  datetimeField < '2/1/2011'

чем это

SELECT SomeFields FROM oelinhst_sql
WHERE
  Month(datetimeField) = 1
  and
  year(datetimeField) = 2011

даже если возвращаемые строки совпадают

Answer 4

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

Вы сказали:

наш номер заказа состоит из шести цифр поэтому у каждого есть два пустых символа ведущий

Заставляет меня думать, что вы храните числа в строке, если так, то почему вы не используете числовой тип данных? Наименьший числовой тип, который будет состоять из 6 цифр, представляет собой INT (я предполагаю, что SQL Server), и он уже экономит 4 байта на номер заказа по сравнению с указанным числом строк, что намного меньше данных для чтения с диска и отправки по сети.

Полностью оптимизируйте свою базу данных, прежде чем пытаться работать с данными вне ее; это то, для чего предназначен сервер баз данных, обслуживающий данные.

Answer 5

Это в некоторой степени зависит от того, что все охватывает: «такие вещи, как обрезка строк», но, по крайней мере, для обрезки строк я бы определенно позволил базе данных сделать это (будет также меньше сетевого трафика). Что касается индексов, они по-прежнему будут использоваться, если вы находитесь там, где предложение просто использует сам столбец (в отличие от функции столбца). На использование индексов никак не повлияет использование функций в реальных столбцах, которые вы извлекаете (только в том, как вы выбираете строки).

Возможно, вы захотите взглянуть на это для предложений по улучшению производительности: http://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/