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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

надеюсь, что это помогает.

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

вот несколько предложений, которые я хотел бы для вас;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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