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

Question

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

Говоря о дизайне базы данных, проверьте нормализацию базы данных, например, статья в википедии: Нормальные формы .

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

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

Answer 4

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

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

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

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

Если столбец Orders.CustomerId является обязательным, нет необходимости использовать левое соединение.

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Answer 7

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

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