Особый случай Equi Join

Question

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

SELECT * 
FROM 
per_assignments a, per_assigment_types b
WHERE
a.assignment_status_type_id + 0  = b.assignment_status_type_id

Почему в экви-соединение добавляется ноль? Я узнал, что это связано с тем, чтобы избежать поиска по индексу, но все же может кто-то объяснить полную картину того же самого. Заранее спасибо

Редактировать:

Это не то, что связано с объявлениями таблицы / столбца. Насколько я знаю, это как-то связано с настройкой SQL.

Вот что я нашел: -

1. Используется в небольших таблицах.
2. Вместо поиска по индексу, как это обычно делается, поиск по всей таблице будет выполнен за один раз.

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

Было бы очень полезно, если бы кто-то мог описать в определенном контексте, а также сообщить мне, если мои выводы неверны. Цените свое время и усилия за то же самое: -)

Описание столбца :

Идентификаторы типа статуса присвоения в обеих таблицах объявлены как NUMBER (9)

Answer 1

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

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

У меня есть вопросы по настройке этих запросов:

1. Каковы точные определения таблиц, включая то, насколько полными являются столбцы VARCHAR (если есть) в среднем?
2. Сколько строк в каждой таблице?
3. Сколько строк добавляется к каждой таблице в день?
4. Как часто выполняется этот запрос?
5. Кто-нибудь рассчитывал, что они запросят выполнение с обеими опциями, чтобы увидеть, какая из них быстрее?

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