Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Firebird наследует недокументированную возможность, которая может ускорить выполнение запроса при некоторых условиях. Это RDB$DB_KEY (обычно называется просто db key), внутренний ключ, поддерживаемый сервером базы данных для внутреннего использования при оптимизации запросов и управлении версиями записей. Внутри контекста транзакции, где он используется, он представляет позицию строки в таблице8[118].

Относительно RDB$DB_KEY

Первый урок заключается в том, что RDB$DB_KEY является прямым указателем, связанным с базой данных, а не с физическим адресом на диске. Второй - значения RDB$DB_KEY не следуют в предсказуемой последовательности. Не используйте вычисления, включающие их относительные позиции! Третий урок в том, что они изменчивы - они изменяются после резервного копирования и последующего восстановления, а иногда и после подтверждения транзакции. Главным является понимание мимолетности db key и отсутствие предположений о его существовании в то время, когда ссылающаяся на него операция завершается или отменяется.

Размер RDB$DB_KEY

Для таблиц RDB$DB_KEY использует 8 байт. Для просмотров он использует коэффициент умножения этих 8 байт, сколько таблиц используется в просмотре. Например, если просмотр соединяет три таблицы, его RDB$DB_KEY использует 24 байт. Это важно, когда вы работаете с хранимыми процедурами и собираетесь сохранять RDB$DB_KEY В переменных. Вы должны использовать тип данных CHAR(n) корректной длины.

По умолчанию db key возвращается в виде шестнадцатеричного числа - две шестнадцатеричные цифры представляют каждый байт: 16 шестнадцатеричных цифр возвращаются для 8 байт. Сделайте для одной из ваших таблиц в isql следующее:

SQL> SELECT RDB$DB_KEY FROM MYTABLE;

RDB$DB KEY

000000B600000002

000000B600000004

000000B600000006

000000B600000008

000000B60000000A

Преимущества

Поскольку RDB$DB KEY напрямую указывает на место хранения записи, он будет быстрее для поиска, чем первичный ключ. Если по каким-то причинам в таблице нет первичного ключа или активного уникального индекса, или уникальный индекс допускает пустые значения, то возможно существование полных дубликатов строк. В этих условиях RDB$DB_KEY является единственным способом точной идентификации каждой строки.

Некоторые виды операций выполняются быстрее в хранимой процедуре при использовании RDB$DB_KEY- обычно в случаях изменения и удаления при сложных условиях. Для добавлений (даже при огромных пакетах) RDB$DB_KEY недоступен, потому что не существует способа определить заранее, какими будут значения.

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

Оптимизация запросов

Проблемы с производительностью, скорее всего, возникнут, если вы попытаетесь запустить изменения DSQL, похожие на следующий пример, для большой таблицы:

UPDATE TABLEA А

SET A.TOTAL = (SELECT SUM (B.VALUEFIELD)

FROM TABLEB В

WHERE B.FK = A.PK)

WHERE <условия...>

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

CREATE PROCEDURE ...

. .

AS

BEGIN

FOR SELECT B.FK, SUM(B.VALUEFIELD) FROM TABLEB В

GROUP BY B.FK

INTO :B_FK, : TOTAL DO

UPDATE TABLEA A SET A.TOTAL = :TOTAL

WHERE A.PK = :B_FK

AND ...

END

Хотя это и быстрее, тем не менее остается проблема, что записи в А выбираются по первичному ключу каждый раз, когда выполняется проход по циклу FOR ... DO.

Некоторые люди получают лучший результат при этом необычном синтаксисе:

. . .

DECLARE VARIABLE DBK CHAR (8);

/* 8 символов для db_key таблицы А */

. . .

FOR SELECT B.FK,

SUM(B.VALUEFIELD) ,

A. RDB$DB_KEY

FROM TABLEB В

JOIN TABLEA A ON A.PK = B.FK

WHERE <условия>

GROUP BY B.FK, A.RDB$DB_KEY

INTO :B_FK, :TOTAL, :DBK DO

UPDATE TABLEA SET A.TOTAL = :TOTAL

WHERE A.RDB$DB_KEY = :DBK;

! ! !

ПРИМЕЧАНИЕ. В Firebird нет необходимости в ключевом столбце для создания соединения, однако он нужен в списке SELECT, чтобы предложение GROUP BY было допустимым.

. ! .

Перечислим преимущества такого подхода.

* Фильтрация общих записей для А и В будет эффективной, когда оптимизатор может создать хороший фильтр для явного соединения.

* Если соединение может применить свое собственное предложение поиска, то существует выгода от выполнения фильтрации до того, как изменение будет проверять свое собственное условие.

* Строки таблицы правой стороны (А), локализованные с помощью прямых указателей db key, выделяются во время соединения быстрее, чем при просмотре первичного ключа или его индекса.

Добавления

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

Однако не все входные значения(VALUE2) оператора INSERT получаются так просто.