Методы оптимизации базы данных для любителей

Question

Можем ли мы получить список основных методов оптимизации (что угодно: от моделирования до запросов, создания индексов, представлений до оптимизации запросов). Было бы неплохо иметь список из них, по одному методу за каждый ответ. Спасибо за внимание, что я считаю это очень полезным.

И ради того, чтобы не быть слишком расплывчатым, допустим, что мы используем базовую БД, такую ​​как MySQL или Oracle, и что БД будет содержать 500 000-1 м или около того записей через ~ 10 таблиц, некоторые с внешними ключами , все с использованием наиболее типичных систем хранения (например, InnoDB для MySQL). И, конечно же, определяются основы, такие как ПК, а также ограничения FK.

Answer 1

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

• Каждая таблица должна иметь кластерный индекс
• Поля, используемые для фильтров и сортировок являются хорошими кандидатами для индексации
• Более селективные поля являются лучшими кандидатами для индексации
• Для достижения наилучших результатов по ключевым запросам дизайн «покрывающих индексов» для этих запросов
• Убедитесь, что ваши индексы фактически используются и удаляют те, которые не являются
• Если таблица содержит 15 полей, и вы делаете 15 индексов, каждый из которых имеет только одно поле, вы делаете это неправильно :)

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

Answer 2

При обсуждении структуры базы данных проверьте нормализацию базы данных, например. статья в википедии: Normal forms.

Если у вас хороший дизайн и вам еще нужно оптимизировать производительность, попробуйте Denormalisation.

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

Answer 3

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

Answer 4

Дизайн, который кратко моделирует вашу проблему, всегда является хорошим началом. Переопределение модели данных может привести к проблемам с производительностью. Например, я слышал отчеты о проектах, стремящихся к гибкости, которые используют RDBMS в качестве немого хранилища «имя/значение», и итоговая производительность была ужасающей.

Как только хороший дизайн на месте, затем используйте инструменты, предоставляемые СУРБД, чтобы помочь ему достичь хорошей производительности. Однополевые PK (без композитов), но составные бизнес-ключи как индекс с уникальным ограничением, использование соответствующих типов данных, например. используя соответствующие числовые типы для числовых значений, а не символов или аналогичных.Физические атрибуты аппаратного обеспечения, на которых работает RDBMS, также должны учитываться, поскольку основная часть времени запроса часто является дисковым вводом-выводом - но, конечно же, не считайте это само собой разумеющимся - используйте профилировщик, чтобы узнать, куда идет время ,

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

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

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

Answer 5

Некоторые оптимизации запроса/схемы:

• Будьте внимательны при использовании DISTINCT или GROUP BY. Я нахожу, что многие новые разработчики будут использовать DISTINCT в тех местах, где это действительно не нужно или может быть переписано более эффективно с использованием инструкции Exists или производного запроса.

• Помните о левых соединениях. Слишком часто я нахожу, что новые разработчики SQL игнорируют схему на месте и используют Left Joins, где они действительно не нужны. Например:

Select 
From Orders 
    Left Join Customers 
     On Customers.Id = Orders.CustomerId

Если Orders.CustomerId это требуется столбец, то не надо использовать левое соединение.

• Будьте учеником новых возможностей. В настоящее время MySQL не поддерживает выражения common-table, что означает, что некоторые типы запросов громоздки и, вероятно, медленнее писать, чем если бы они поддерживались CTE. Однако это не будет вечно. Следите за новыми возможностями синтаксиса в MySQL, которые могут быть использованы для повышения эффективности существующих запросов.

• Вам не нужно использовать суррогатные ключи повсюду. Там могут быть таблицы, более подходящие для интеллектуального ключа (например, аббревиатуры США, коды валют и т. Д.), Которые позволят разработчикам во многих случаях избегать дополнительных объединений.

• Если возможно, найдите способы архивирования данных на OLAP или сервер отчетов. Чем меньше вы можете сделать производственные данные, тем быстрее он будет работать.

Answer 6

Возьмите целостный подход к оптимизации.

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

Answer 7

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

Хорошим примером является Модифицированный PREORDER дерева Transversal (MPTT), чтобы получить все из дерева узлов родителей, заказал, в одном запросе.