為什麼 SQL Server Management Studio 有時會繞過子查詢中的語法驗證？

SQL Server Management Studio：意外的子查詢行為

SQL Server Management Studio (SSMS) 在處理包含引用無效欄位的子查詢的查詢時有時會表現出意外的行為。 雖然 SSMS 通常會執行語法驗證，但在特定情況下它可能會令人驚訝地忽略這些錯誤，從而給開發人員帶來困惑。

考慮這個例子：

<code class="language-sql">delete from Photo where hs_id in (select hs_id from HotelSupplier where id = 142)</code>

此查詢旨在根據從 Photo 中選擇的子查詢中找到的 hs_id 值從 HotelSupplier 表中刪除條目。 然而，HotelSupplier 缺少 hs_id 字段；它使用 hs_key 代替。

有趣的是，儘管子查詢本身在獨立運行時失敗，但該查詢在 SSMS 中執行時通常不會出錯：

<code class="language-sql">select hs_id from HotelSupplier where id = 142</code>

解釋

SSMS 的行為源自於其對不合格列引用的處理。 它將 hs_id 引用解釋為屬於外部查詢 (Photo)，而不是子查詢。 這遵循從最外層範圍向內解析不合格列名的規則。

由於子查詢沒有明確選擇任何列，SSMS 有效地將查詢重寫為：

<code class="language-sql">delete from Photo where Photo.hs_id in (select * from HotelSupplier where id = 142)</code>

如果子查詢傳回任何行（就像這裡可能做的那樣），這將刪除 Photo 中的所有行，其中 hs_id 不為 NULL。 子查詢的非空結果集會導致 IN 子句對於非 NULL 值求值為 true。

重點

這種看似違反直覺的行為強調了在 SQL 查詢中使用完全限定列名（例如 HotelSupplier.hs_key）的重要性。 這種做法可以防止歧義並確保可預測的查詢執行，避免意外的資料刪除或其他意外後果。

以上是為什麼 SQL Server Management Studio 有時會繞過子查詢中的語法驗證？的詳細內容。更多資訊請關注PHP中文網其他相關文章！