Читать онлайн «Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ». Страница 73

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

! ! !

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

. ! .

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

Индексы являются атрибутами таблицы, которые могут содержать один столбец или группу столбцов для ускорения поиска строк.

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

Firebird допускает до 256 определенных пользователем индексов на одну таблицу в версии 1.5 и выше, и 64 в более ранних релизах. Однако это теоретические ограничения, которые могут быть скорректированы за счет размера страницы и фактического размера на диске данных описания индекса в корневой странице индекса. Вы не сможете хранить 256 индексов в базе данных с размером страницы менее 16 Кбайт. На корневой странице индекса каждому индексу нужен 31 байт для его идентификатора, место для описания каждого сегмента (столбца), включенного в состав индекса, и несколько байтов для хранения указателя на первую страницу индекса. Даже страница в 16 Кбайт может не оказаться способной хранить 256 индексов, если в базе данных существует немало составных индексов.

Для создания индексов пользователь должен иметь право соединяться с базой данных.

Общая длина индекса не может превышать 252 байта. В реальности количество байт может быть значительно меньше. Факторами, которые могут уменьшить количество фактических "мест", доступных для хранения символов, являются:

* интернациональные наборы символов, использующие несколько байт на символ;

* интернациональные наборы символов со сложными парами верхний/нижний регистры и/или сложным словарем правил сортировки;

* использование недвоичных порядков сортировки;

* множество сегментов (составной индекс), которые требуют дополнительных пустых байтов для сохранения геометрии индекса.

Другими словами, использование любого набора символов за исключением NONE будет влиять на ваши решения по проектированию индексов - особенно на использование составных индексов. Это плохие новости. Хорошие новости- Firebird правильно использует индексы из одного столбца в многостолбцовых поисках и сортировках, сокращая потребность в многостолбцовых индексах, которые вы могли использовать в других СУБД.

Firebird автоматически создает индексы для обеспечения различных ограничений целостности (более подробную информацию см. в главах 16 и 17). Для удаления таких индексов необходимо удалить ограничения, которые их используют.

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

При определении ваших собственных индексов крайне важно исключить создание любых индексов, которые дублируют автоматически сгенерированные индексы. Это ставит оптимизатор (см. разд. "Планы запросов") в печальную ситуацию выбора между равными индексами. В большинстве случаев он разрешит проблему, не выбрав ни одного.

Не импортируйте "первичные индексы" таблиц при миграции из другой СУБД. Есть две важные причины отказаться от таких индексов.

* Многие существующие системы используют иерархические структуры индексов для реализации ссылочной целостности. Базы данных SQL не используют подобную логику для реализации ссылочной целостности. Такие индексы обычно влияют на логику оптимизатора Firebird.

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

Направление сортировки индексов в Firebird является важным. Ошибочно было бы предполагать, что один и тот же индекс может быть использован для сортировки или поиска "в обоих направлениях" - от меньшего к большему и от большего к меньшему. В практике индексы ASC (ASCENDING, в возрастающем порядке) помогут в поиске относительно небольшого количества значений, в то время как индексы DESC (DESCENDING, В убывающем порядке) будут полезными при большом количестве значений.

Если автоматический индекс ASC (по умолчанию), то не будет проблем, если вам нужно определить индекс DESC, использующий тот же столбец (столбцы). Обратное также верно: в Firebird 1.5 и выше вы можете выбрать для автоматически создаваемых индексов убывающий порядок. Оптимизатор не "расстроится", если вы также создадите возрастающий индекс для тех же столбцов.

Перед выполнением запроса комплект программ подготовки - известный как оптимизатор- начинает анализировать столбцы и операции запроса для вычислен? самого быстрого способа выполнения. Подготовка начинается с просмотра индексов таблицы и используемых столбцов. Работая таким образом с последовательностью путей решения (каждый из которых имеет свою "стоимость"), оптимизатор создает план - некий вид "дорожной карты" того пути, по которому сервер будет следовать при выполнении запроса. Конечный план выбирается по критерию "самой дешевой" дороги, оцениваемой в соответствии с индексами, которые могут быть использованы.

План оптимизатора может быть просмотрен в isql двумя способами.

* По умолчанию isql не отображает план. Используйте SET PLAN ON для отображения плана в самом начале вывода запроса SELECT.

* Используйте SET PLANONLY для рассмотрения запроса и просмотра плана без фактического выполнения запроса. Это позволяет вам анализировать план любого запроса, а не только запросов SELECT.

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

! ! !

СОВЕТ. Не перекрывайте план оптимизатора, пока вы не протестировали ваш собственный и не убедились, что он выполняется быстрее на реальных данных.

. ! .

Более подробную информацию о планах запроса см. в разд. "Тема оптимизации" главы 20. Подробности использования isql см. в главе 37.

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

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

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