Как повысить производительность базы данных?

Question

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

Если бы вас попросили повысить производительность базы данных, которая содержит около 250 таблиц и несколько таблиц с миллионами записей, что бы вы искали?

Заранее спасибо.

Answer 1

Оптимизировать логический дизайн

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

• Иметь наиболее эффективные запросы SQL
• Разработка логической схемы, поддерживающей потребности приложения (например, тип столбцов и т. Д.)
• Разработка компромисса для поддержки некоторых вариантов использования лучше, чем другие
• Реляционные ограничения
• Нормализация

Оптимизировать физический дизайн

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

• Таблицы параметров (размер размещения и т. Д.)
• Индексы (комбинированные, типы и т. Д.)
• Общесистемные параметры (размер кэша и т. Д.)
• Разметка
• Денормализация

Попробуйте сначала улучшить логический дизайн, а затем физический дизайн. (Граница между обоими, однако, неясна, поэтому мы можем поспорить о моей классификации).

Оптимизация обслуживания

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

• Вести статистику в актуальном состоянии
• Периодически повторять критические таблицы
• Обслуживание дисков
• Все системные вещи, чтобы иметь сервер, который качается

Answer 2

Сжатие . Для подавляющего большинства нагрузок, которые я пробовал, использование сжатия было огромной бесплатной поездкой. Уменьшенный размер данных означает меньший объем ввода-вывода и лучшую пропускную способность. В SQL Server 2005 параметры сжатия ограничены (vardecimal). Но я бы серьезно подумал о переходе на 2008 год только для сжатия страниц. Или 2008 R2, если вы часто используете nvarchar для сжатия Unicode.

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

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

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

И последнее, но не менее важное: понять скрытую стоимость различных решений «под ключ». Например, репликация или зеркальное отображение базы данных.

Answer 3

Это очень расплывчатый вопрос.

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

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

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

Если у вас все еще есть проблемы с производительностью, денормализация иногда может помочь - но все зависит от ситуации.

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

Answer 4

Мой ролик на MySpace был «Повышение производительности DBA / Developer». Я бы сказал, что нормализация и индексы являются требованием в высокопроизводительных базах данных, но вы должны действительно проанализировать свои структуры таблиц и индексы, чтобы действительно раскрыть возможности проектирования баз данных.

Вот несколько предложений для вас;

1. Познакомьтесь с движком БД. Сквозное знание подчеркивающей структуры ввода / вывода очень важно для разработки правильного индекса или таблицы. Используя PerfMon и Profiler, наряду с вашими знаниями о том, что такое операции ввода-вывода для чтения / записи, вы можете поставить некоторые очень конкретные цифры за теорией того, что такое правильно сформированное решение для таблиц и индексов.

2. Понять разницу между кластеризованными и некластеризованными индексами и когда использовать какой.

3. Используйте sys.dm_os_waiting_tasks и sys.dm_os_wait_stats DMV. Они скажут вам, куда вы должны приложить усилия для сокращения времени ожидания.

4. Используйте DBCC SET STATISTICS IO / TIME ON и оцените свои планы выполнения, чтобы увидеть, уменьшает ли один запрос или увеличивает количество чтений или длительность страниц.

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

6. Оценить грязные чтения (nolock, читать без передачи). Если вы можете покончить с точностью до миллисекунды при чтении, сохраните блокировки!

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

8. Перегородки в больших таблицах имеют большое значение - только если правильно спроектированы.

9. Изменения в приложениях. Если вы можете запланировать пакетные обновления для асинхронных транзакций, поместите их в кучу без индекса и обрабатывайте ее по расписанию, чтобы не обновлять таблицы, которые вы интенсивно запрашиваете.

10. Всегда Всегда Всегда !!! используйте ту же переменную типа данных для запроса целевых столбцов; Например, следующий оператор использует переменную bigint для столбца smallint:

объявить @i bigint установить @i = 0

выберите * из MyTable, где Col01SmallInt> = @ i

В процессе оценки страниц индекса / таблицы механизм запросов может выбрать преобразование данных столбца smallint в тип данных bigint. Вместо этого рассмотрите возможность изменения типа varialbe или, по крайней мере, преобразования его в smallint в ваших условиях поиска.

11. SQL 2005/08 предоставляет вам «Отчеты» в приложении управления, взгляните на отчеты о работе ваших индексов. Они сканируются, разыскиваются? когда было ваше последнее сканирование таблицы? Если это было недавно, ваши индексы не выполняют все необходимые запросы. Если у вас есть индекс, который почти не используется (ищется или сканируется), но постоянно обновляется, рассмотрите возможность его удаления. Это может сэкономить вам много ненужных блокировок строк и блокировок клавиш. ..

Это все, что я могу думать о макушке. Если вы столкнетесь с более конкретной проблемой, у меня будет более конкретный ответ для вас ..

Answer 5

Есть много вещей, которые вы могли бы сделать, многие из них уже предложены выше. Некоторые, на которые я бы посмотрел (в таком порядке):

• Ошибки / журналы - многие движки БД имеют инструменты отчетности, которые указывают на проблемные области в базе данных. Начните здесь, чтобы узнать, можете ли вы сосредоточиться на чем-то прямо сейчас.
• Хранение данных - проверьте спецификацию бизнеса, как долго должны храниться данные, убедитесь, что все более старые данные перемещены в хранилище данных, чтобы размер таблицы был небольшим. (Зачем хранить данные за 5 лет, если нужны только последние 3 месяца?)
• Ищите таблицы сканирования, индексируйте данные, если это поможет (вы должны сравнить это с записями таблицы). Журналы вашего сервера, вероятно, могут помочь вам при поиске таблиц.
• Атомные элементы работы, некоторые записи сохраняют блокировки на разных таблицах до достижения точки фиксации? Можно ли упростить эти элементы работы или перенести точки фиксации для повышения производительности? Здесь вам понадобится разработчик, чтобы посмотреть на код.
• Ищите длительные операторы SQL, можно ли сделать их более эффективными? Иногда плохо структурированные запросы могут привести к сбою приложения. Возможно, вам придется предложить изменить кодировку для повышения производительности.
• dba realm: посмотрите, как распределяются таблицы: размер страницы, несколько сегментов и т. Д. Здесь полезны инструменты диагностики от поставщика, поскольку они часто могут подсказать, как можно структурировать таблицу на основе истории использования. Опытный дба будет здесь полезен.
• поиск аппаратных / сетевых узких мест. Это где вам понадобится аппаратный парень. :)

Это действительно высокий уровень, я бы также взглянул на то, что производитель вашего движка БД предлагает для повышения производительности.

Кроме того, я бы сравнил такой список с тем, за что мой босс готов платить и сколько у меня есть времени. ;)

Надеюсь, это поможет.

Answer 6

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

Answer 7

Чтобы повысить производительность, вам необходимо сначала проконтролировать вашу базу данных. Вы можете отследить и затем загрузить его в SQL Server Profiler, чтобы выяснить, какие запросы являются самыми медленными. После этого вы можете сосредоточиться на них.

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

Answer 8

Если запрос чрезвычайно важен для миссии, вы можете рассмотреть вопрос о нормализации de , чтобы уменьшить количество операций поиска в таблице на запрос. Кроме того, если вам требуется более высокая производительность, чем та, которую могут выполнять индексирование и денормализация, вам может потребоваться посмотреть на программную сторону: кэширование, оптимизация запросов / хранимых процедур и т. Д.

Answer 9

Мы не написали об одном бите производительности:

Оборудование.

Базы данных интенсивно управляются вводом / выводом. Переход на более быстрый жесткий диск должен увеличить скорость запросов к базе данных. Распределение базы данных по множеству быстрых жестких дисков может улучшить ее еще больше.

Answer 10

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