與具有幾百萬行的表上的“=”相比，SQL Server“<>”運算符非常慢

Question

我有兩張桌子。 表單有~77000行。 日志有大約270萬行。

以下查詢在不到一秒的時間內返回“30198”：

SELECT COUNT(DISTINCT logs.DOCID) FROM logs, forms WHERE logs.DOCID = forms.DOCID;

此查詢到目前為止已運行約15分鍾，但仍未完成：

SELECT COUNT(DISTINCT logs.DOCID) FROM logs, forms WHERE logs.DOCID <> forms.DOCID;

為什么是“不等於”查詢，以便更慢？

Answer 1

因為=將連接操作減少到每個表中的一個匹配行（假設這些docid是唯一的）。

想一想 - 你和5個男孩和5個女孩一起跳舞：

Adam      Alice
Bob       Betty
Charly    Cathy
Dick      Deb
Evan      Elly

你用第一個字母將它們配對。 所以

Adam->Alice
Bob->Betty
etc...

一對配對

但是，如果你通過“首字母不匹配”將它們配對，你最終得到：

Adam->Betty
Adam->Cathy
Adam->Deb
Adam->Elly
Bob->Alice
etc...

你已經大量增加了配對次數。 這就是你的<>查詢花了這么長時間的原因。 您實際上是在嘗試獲取mxn行，而不僅僅是min(m,n) 。 使用這些數據，最終會得到25行，而不是5行。對於指定的表格大小，您使用的是77,000 * 2,700,000 = 207.9億行，減去77,000，其中兩個ID匹配，總共207,899,923,000行連接的數據集。

---

根據您的查詢要求，嘗試左連接並查找空的右側記錄：

SELECT DISTINCT logs.DOCID
FROM logs
LEFT JOIN forms ON logs.DOCID = forms.DOCID
WHERE forms.DOCID IS NULL

Answer 2

兩個原因：

• 對等價的查詢通常可以使用索引（如果可用），而查詢不等價則不能

• <>返回更多數據。

您對<>查詢是假的。 應該歸還什么？

Answer 3

這完全取決於表中值的分布。 例如，如果要搜索的列對99.99％的行具有相同的值(= forms.DOCID) ，而只有一行具有不同的值，則會看到完全相反的行為。