Equi加入的特殊情況

Question

我遇到了使用特殊形式的equi加入的特殊腳本。

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. 不像通常那樣進行索引搜索，而是一次搜索完整的表格。

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

如果有人可以在特定的環境中描述並且讓我知道我的發現是否是錯誤的，那將會非常有幫助。感謝您的時間和精力一樣:-)

列說明：

分配狀態類型標識的兩個表中被聲明爲NUMBER（9）

Answer 1

原因殺死指數使用對於小桌子來說就是表現。當您使用索引執行連接時，需要兩個磁盤I/O來讀取數據。一個讀取索引，另一個讀取全表中的數據。對於較小的表，讀取整個表並執行全表掃描比執行第二個磁盤I/O的速度更快。

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

我有關於調整這些疑問將是問題：

1. 什麼是表的準確定義，包括如何充分是VARCHAR列（如果有的話），平均？
2. 每個表中有多少行？
3. 每天有多少行添加到每張表中？
4. 此查詢執行的頻率如何？
5. 有沒有人計時他們查詢執行與兩個選項，看哪個更快？

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