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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

хороший пример -Изменено Дерево Предзаказа Transversal (MPTT), чтобы получить все родители узла дерева, упорядоченные, в одном запросе.

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

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