Производительность является одним из ключевых факторов, определяющих пригодность сервера СУБД для использования в конкретном приложении. Производительность определяет максимальную нагрузку, которую сервер может нести на выбранной аппаратной платформе, выраженную, например, в количестве одновременно работающих пользователей или количестве операций, выполняемых в единицу времени. К сожалению, скоростные характеристики линейки серверов InterBase часто уступают показателям конкурентов, таких, как MSSQL или Sybase SQL Anywhere. По производительности Yaffil далеко опережает своих аналогов из клона InterBase. При выполнении тех же самых запросов Yaffil работает в 2-3 раза быстрее, чем InterBase 6.0 и Firebird 1.0. Такие результаты достигнуты благодаря многочисленным улучшениям алгоритмов и оптимизацией кода, большое число критических алгоритмов переписаны на ассемблере х86 убраны ненужные системные вызовы

Оптимизатор - своего рода "мозг" сервера, и степень его интеллектуальности может кардинально повлиять на скорость работы приложений. Неверно выбранный план может привести к увеличению времени выполнения запроса в тысячи раз. За время своей эволюции от версии InterBase 4.0, не способной вообще оптимизировать явные соединения, и до последних версий в оптимизатор InterBase разработчиками Borland вносились изменения, которые хотя и приводили к улучшению планов для определенных случаев, но часто непредсказуемо сказывались на других запросах. Например, в пятой версии InterBase научился корректно оптимизировать соединения в явном синтаксисе ANSI SQL, но другой способ выборки индексов в ряде случаев приводил к катастрофическому увеличению времени выполнения запросов. Подобные неприятности появились в версии 6.0, в результате многие разработчики не могли перенести свои системы на современную платформу.

Проанализировав большое число проблемных случаев с оптимизацией InterBase версий 4.x, 5.x и 6.x, разработчики Yaffil внесли ряд улучшений, в результате чего в большинстве случаев можно вообще отказаться от применения ручных планов При этом при переходе на Yaffil со старых версий InterBase случаев ухудшения автоматических планов практически не наблюдается.

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

Перечислим некоторые улучшения оптимизатора Yaffil.

Выбор индекса с меньшим числом полей при наличии индекса с большим числом полей

Этот случай часто возникает, когда в таблице имеется большое количество индексов, в том числе составных. Оптимизатор Interbase/Firebird всегда пытался выбрать индекс, который охватывает множество полей, в то время как существовал более быстрый и компактный индекс. Оптимизатор Yaffil автоматически разрешает данную ситуацию. Вот пример: Таблица из трех полей Table 1 (Fl, F2, F3) На нее созданы три индекса: IDX_F1(F1), IDX_F1_F2(F1,F2), IDX_F1_F2_F3(F1,F2,F3) Выполняем запрос:

select * from Tablel where Fl = параметр

Получаем следующие планы для использования индексов: Interbase 6.5/FireBird 1.0:

PLAN (Т INDEX (IDX_F1_F2_F3))

Yaffil:

PLAN (T INDEX (IDX_F1))

Interbase 6.5/FireBird 1.0 используют индекс с максимальным количеством полей, хотя очевидно, что в данном случае надо использовать единственный индекс по полю F1, как это и делает Yaffil. Это очень распространенная ошибка, приводящая к замедлению выполнения запроса, обойти которую без явного планирования достаточно сложно.

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

Этот случай возникает, когда выборка делается по одному полю, а сортировка - по другому, при этом имеется индекс по обоим полям. Пример: пусть существует таблица из трех полей T(F1,F2,F3), есть индексы на следующие сочетания полей: на одно поле IDX_F1(F1), на два первых поля IDX_F1_F2(F1,F2), на все три поля IDX_F1_F2_F3(F1,F2,F3).

Производим запрос следующего вида:

select * from T where Fl=.. order by F2

Получаем планы следующего вида:

FireBird/InterBase 6.5:

PLAN SORT(Т INDEX (IDX_F1_F2_F3))

Yaffil:

PLAN (T ORDER (IDX_F1))

Исключение из обработки индексов с сильно различающейся селективностью

Пример: пусть у нас есть таблица из трех полей T(F1,F2,F3) с индексами на каждое поле IDX_Fl(Fl), IDX_F2(F2) и IDX_F3(F1). Пусть здесь F1 является уникальным полем (первичный ключ, например), a F2 - неуникальным. Производим запрос:

select * from Т where Fl = параметр! and F2 = параметр2 ...

В результате получаем следующие планы: FireBird/InterBase 6.5:

PLAN (Т INDEX (IDX_F1, IDX_F2))

Yaffil:

PLAN (Т INDEX (IDX_F1))

Оптимизатор Yaffil всегда объединяет индексы с учетом селективности.

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