Целесообразность создания индексов

Индексы необходимо создавать в случае, когда по столбцу или группе столбцов:

• Часто производится поиск в БД;

• Часто строятся объединения таблиц;

• Часто производится сортировка;

• Часто производится сортировка;

Не рекомендуется строить индексы по столбцам или группам столбцов, которые:

• Редко используются для поиска, объединения , сортировки результатов запроса

• Часто меняют значение, что приводит к необходимости часто обновлять индекс и способно существенно замедлить скорость работы с БД;

• Содержит небольшое число вариантов значения

Частичное использование составного индекса

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

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

Порядок следования условий по столбцам в предложении WHERE оператора SELECT не важен (если условия объединяются по AND).

Многопоточность поиска по or и in

При частом использовании в условной части WHERE оператора SELECT нескольких столбцов, между собой операцией «или» (OR)Ж

SELECT *

WHERE A=100 OR B=200 OR C= 300

вместо индекса по столбцам A,B,C лучше создать несколько индексов, построенных по каждому из этих полей, поскольку в противном случае будет осуществлен последовательный просмотр всей таблицы.

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

Отдельный поток поиска порождает и каждый элемент в списке IN. Например,

WHERE A IN (100, 200, 300)

интерпретируется как

WHERE A=100 OR A=200 OR A=300 .

Однако при указании диапазона BETWEEN

WHERE A BETWEEN 100 AND 300

этого не происходит. Поэтому, где возможно, следует заменять IN на BETWEEN.

Уменьшение общего количества индексов.

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

3.9.5.Оптимизация клиентских приложений

Минимизация соединений с БД

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

Использование SQL-ориентированных компонентов при построении клиентских приложений

Использование SQL-ориентированных компонентов (например, в Delphi компонент TQuery вместо TTable) позволяет уйти от «навигационного способа» обработки данных, который был характерен для локальных и файл-серверных СУБД, и, как следствие, решает задачу снижения трафика в вычислительной сети.

Перенос тяжести вычислительной работы на сервер

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

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

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

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

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