Топ-10 узких мест в SQL Server

Что является наиболее распространенным узким местом производительности, которое не вызвано структурой базы данных?

ОТВЕТЫ

Ответ 1

Посмотрим (в определенном порядке)

  • курсоры

  • non-sargable where clauses

  • Невозможность индексирования полей внешнего ключа

  • Невозможно индексировать поля, обычно используемые в предложении where

  • взаимосвязанные подзапросы

  • случайные кросс-соединения, вызывающие необходимость различать набор результатов

  • Неверный код, поступающий из ORM

  • Код, который вызывает слишком много чтений или вызывается более одного раза, когда это не нужно (я видел приложения, которые отправляют один и тот же код много раз, когда им это не нужно, или каждый раз, когда страница открыта)

  • Перегрузка сетевой трубы

  • Пользовательские функции, вызывающие обработку по строкам

  • Параметр sniffing

  • устаревшая статистика

  • Союз, а не объединение всех

Ответ 2

сканирование таблицы, потому что:

  • индекс не существует
  • устаревшие данные
  • функции, в которых условие запрещает использование

Ответ 3

  • Сервер - как память и память типы.
  • Сеть - Задержка и пропускная способность вопросы.
  • Индексация - не уверен, если вы считаете эта структура базы данных
  • Запросы - Плохие запросы с присоединением проблемы, которые могут вызвать полную таблицу сканирование.

Ответ 4

Физический.... Запуск из памяти и переход на диск.

Ответ 5

Применение скалярной функции к каждой строке в результирующем наборе

SELECT fn_EveluateSomeValue([ColumnName]) FROM LargeTable

Ответ 6

Использование курсоров. Для любой базы данных.

Ответ 7

Использование табличных данных по одной строке за раз, а не по одной таблице за раз (т.е. курсоры).

Ненужные (или плохо спроектированные) блокировки.

Журналы регистрируют вещи, которые не нужно регистрировать (удалить из таблицы вместо таблицы Truncate и т.д.)

Наличие ограничений при загрузке данных. Серьезно замедляет вставку. Выключите их, загрузите данные, затем включите их.

Ответ 8

Ditto ref cursors, также плохо написанные клиентские приложения, которые получают огромный набор записей, затем обрабатывают его сами, потому что разработчик не понял, что sql был чем-то большим, кроме огромной кучи для хранения данных.

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

Не имеет индексов для объединений или обычно запрашиваемых полей.

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

Ответ 9

Некоторые низко висящие фрукты:

  • Скалярные UDF
  • опускание text() в запросах XPath
  • недостающие столбцы в индексах (вызывание ключевых запросов)
  • с помощью курсоров
    • не использовать fast_forward, когда это возможно, когда курсоры необходимы
  • с помощью JOIN, когда будет выполняться APPLY, или наоборот (test!)

Ответ 10

Триггеры могут быть ОГРОМНЫМ узким местом (и головной болью) при обработке больших партий команд.

Ответ 11

Если система ввода-вывода на сервере не соответствует заданию, вы можете получить конфликт затвора на tempdb, и это, в свою очередь, может вызвать серьезные проблемы с производительностью.

Ответ 12

Я склоняюсь к следующим узким местам (по порядку частоты):

  • Отсутствующие или неверные индексы (в результате чего сканируются таблицы)
  • Плохо написанные запросы
  • Контекст ввода/вывода

Ответ 13

Наличие плохой конфигурации my.cnf может убить сервер даже при правильном проектировании и индексировании базы данных. Читайте:

http://www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/ http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/

http://www.mysqlperformanceblog.com/2007/08/18/how-fast-can-you-sort-data-with-mysql/ http://www.mysqlperformanceblog.com/2007/09/17/mysql-what-read_buffer_size-value-is-optimal/

http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html

Полезный аналитический инструмент my.cnf: http://www.day32.com/MySQL/tuning-primer.sh

Ответ 14

Мне никогда не удавалось найти много полезной информации о распаде больших запросов, в Oracle кажется, что вам больше рекомендуется хранить все вместе в одном запросе, а не использовать временные таблицы. Вы также можете получить проблемы с журналом повтора, если ваша временная таблица хранит много данных. Я хотел бы узнать больше/получить некоторые ссылки?

Ответ 15

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

Ответ 16

Для нас настройка настроек BIOS и настроек плана мощности привела к тому, что для запросов, интенсивно работающих в ЦП (поиск, продолжительность около 5 секунд), было достигнуто твердое ~ 2 раза быстрее.

1) Настройки BIOS изменились с "Производительность на ватт-оптимизированный (DAPC)" на "Производительность" или "Производительность на ватт с оптимизацией (OS)". Обе опции, похоже, выполнялись аналогичным образом, однако "управляемая ОС" не постоянно приводила вентилятор в макс.

2) План питания Windows был изменен с "Сбалансированный" на "Высокая производительность".

Это было обнаружено после обновления процессоров и почти не улучшилось.

Команда для проверки скорости процессора от SQLServerCentral:

PS> gwmi -class win32_Processor | SELECT CurrentClockSpeed, MaxClockSpeed

Обновление 6/13/2017: Предупреждение: этот номер может сообщить Current = Max, однако диспетчер задач может показать другое (гораздо меньшее) число. Также режим BIOS "Performance Per Watt Optimized (OS)" внезапно прекратил работать для нас после некоторых изменений аппаратного обеспечения. ЦП был заблокирован с максимальной частотой 50%, независимо от нагрузки. Только режим "Производительность" (режим громкоговорителя) все же достиг максимального максимального значения. Нам не хватает патча прошивки/программного обеспечения.

Ответ 17

Оговорки, которые следует избегать (если возможно):

  • DISTINCT/UNIQUE
  • UNION
  • GROUP BY
  • ЗАКАЗАТЬ