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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

• Будьте внимательны при использовании 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 или сервер отчетов. Чем меньше вы можете сделать производственные данные, тем быстрее он будет работать.

Ответ 5

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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