Equi Join的特例

Question

我遇到了這個使用特殊形式的equi join的特殊腳本。

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

為什么在equi連接中添加了零？ 我開始知道它與避免索引搜索有關，但仍然可以解釋相同的完整圖片。 提前致謝

編輯：

它不是與表/列聲明相關的東西。 據我所知，它與SQL調優有關。

這是我發現的： -

1. 這用於較小的表格。
2. 這不是像正常那樣進行索引搜索，而是一次性搜索整個表。

但我真的不知道與正常的等連接有什么區別，而且索引如何影響性能。

如果某人能夠在特定的背景下描述並且讓我知道我的發現是否錯誤，那將是非常有幫助的。 感謝您的時間和精力:-)

欄目描述 ：

兩個表中的分配狀態類型Id都聲明為NUMBER（9）

Answer 1

殺死小表的索引使用的原因是性能。 使用索引執行連接時，需要兩個磁盤I / O來讀取數據。 一個用於讀取索引，另一個用於讀取完整表中的數據。 對於較小的表，讀取整個表並執行全表掃描比執行第二個磁盤I / O更快。

這是一個廣泛的概括，即使在您的數據庫中也可能不時變化。 從理論上講，SQL優化器應該足夠智能以識別這種情況，並且即使沒有提示也可以在索引查找上使用全表掃描。 如果將數據添加到一個或兩個表中，它也可能將更快的性能從全表掃描移動到索引查找。

我對調優這些查詢的問題是：

1. 表的精確定義是什么，包括平均VARCHAR列（如果有）的完整程度？
2. 每張表中有多少行？
3. 每天為每個表添加多少行？
4. 這個查詢多久執行一次？
5. 有沒有人定時用兩個選項查詢執行情況，看看哪個更快？

我擔心的是這個查詢是作為一個聰明的性能增強而編寫的，無論是對於早期版本的數據庫還是僅僅作為一個聰明的黑客而沒有意識到查詢優化器可能做得好或更好。