Что может привести к снижению производительности SQL-сервера?

Question

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

Мой вопрос:

Существуют ли другие приемы, позволяющие повысить производительность сервера SQL?

Какие еще причины могут ухудшить производительность SQL-сервера?

Answer 1

• Неэффективный дизайн запроса
• Автоматически растущие файлы
• Слишком много индексов для таблицы
• Слишком мало индексов на столе
• Неправильный выбор кластерного индекса
• Фрагментация индекса из-за плохого обслуживания
• Фрагментация кучи из-за отсутствия кластерного индекса
• Слишком высокое значение FILLFACTOR, используемое в индексах, что вызывает чрезмерное разбиение страницы
• Слишком низкий FILLFACTOR, используемый в индексах, что приводит к чрезмерному использованию пространства и увеличению времени сканирования.
• Не использовать закрытые индексы, где это уместно
• Используются неселективные индексы
• Неправильное ведение статистики (устаревшая статистика)
• Базы данных не нормализованы должным образом
• Журналы транзакций и обмен данными с одинаковыми шпинделями дисков
• Неправильная конфигурация памяти
• Слишком мало памяти
• Слишком маленький процессор
• Медленные жесткие диски
• Отказ жестких дисков или другого оборудования
• Трехмерная заставка на сервере базы данных, загружающая ваш процессор
• Совместное использование сервера базы данных с другими процессами, которые конкурируют за процессор и память
• Блокировка конфликтов между запросами
• Запросы, которые сканируют целые большие таблицы
• Код переднего конца, который ищет данные неэффективным образом (вложенные циклы, строка за строкой)
• КУРСОРЫ, которые не нужны и / или не являются FAST_FORWARD
• Не задавать NOCOUNT, если вы просматриваете большие таблицы.
• Использование слишком высокого уровня изоляции транзакции (например, использование SERIALIZABLE, когда в этом нет необходимости)
• Слишком много циклов между клиентом и SQL Server (болтливый интерфейс)
• Ненужный связанный запрос к серверу
• Запрос связанного сервера, нацеленный на таблицу на удаленном сервере, для которой не определен первичный или потенциальный ключ
• Выбор слишком большого количества данных
• Чрезмерная перекомпиляция запроса

о, и могут быть и другие.

Answer 2

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

Во-первых, не извлекайте данные, которые вам не нужны. Например, если вы делаете пейджинг, не возвращайте 100 строк, а затем вычисляйте, какие из них принадлежат странице. Пусть сохраненный процесс выяснит это и получит только те 10, которые вам нужны.

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

Answer 3

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

Например, Дейв Маркл говорит, что неэффективные запросы могут стать причиной проблемы, и существует множество способов написания неэффективных запросов и еще много способов их устранения.

Answer 4

Это очень широкий вопрос. И уже есть тонна ответов. И все же я хотел бы добавить один важный фактор - Page Split. Проблема в том, что есть хорошие и плохие сплиты. Ниже приведены хорошие статьи, объясняющие, как использовать расширенное событие transaction_log для выявления плохих / неприятных разбиений страницы

1. Отслеживание разбиений проблемных страниц в расширенных событиях SQL Server 2012 - Джонатан Кехайас
2. Отслеживание разбиения страницы с использованием журнала транзакций - Пол Рэндал

Вы упомянули:

Я пытаюсь оптимизировать его, а также добавить несколько индексов

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

Статистика ожидания или, пожалуйста, скажите, где болит дает представление об использовании статистики ожидания для анализа производительности.

Чтобы увидеть свежие идеи для исполнения, взгляните на Вопросы производительности - sqlmag.com

1. Отдельные таблицы в соединениях с различными дисками (для параллельных дисковых операций ввода-вывода - файловые группы).
2. Избегайте объединений в столбцах с несколькими уникальными значениями.

Чтобы понять JOIN, прочитайте Продвинутые техники JOIN

Answer 5

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

В основном вы фиксируете запросы SQL, выполняемые к вашей БД, в SQL Profiler, а затем скорми их ДЕТА.DETA эффективно выполняет запросы (без изменения ваших данных), а затем определяет, какой информации не хватает в вашей базе данных (представления, индексы, разделы, статистика и т. Д.), Чтобы выполнять запросы лучше.

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

PS: Учитывая все вышесказанное, гораздо лучше инвестировать в хорошего администратора баз данных в начале проекта, чтобы у вас были хорошие структуры и индексирование для начала.Но это не та позиция, в которой вы сейчас находитесь ...