首頁猿問 SQL IN是否對性能不利？

SQL IN是否對性能不利？

SQL Server

慕哥6287543 2019-11-28 10:52:52

我有做類似的查詢：SELECT FieldX, FieldY FROM AWHERE FieldW IN (108, 109, 113, 138, 146, 160,307, 314, 370, 371, 441, 454 ,457, 458, 479, 480,485, 488, 490, 492, 519, 523, 525, 534, 539, 543,546, 547, 550, 564, 573, 629, 642, 643, 649, 650,651, 694, 698, 699, 761, 762, 768, 772, 773, 774,775, 778, 784, 843, 844, 848, 851, 852, 853, 854,855, 856, 857, 858, 859, 860, 861, 862, 863, 864,865, 868, 869, 871, 872, 873, 891) 具有很多選項的IN子句是否對查詢性能不利？我的應(yīng)用程序遇到很多超時，我相信這可能是此類問題的根源。是否可以使用任何良好的SQL提示優(yōu)化查詢而不刪除數(shù)字？編輯：@KM這些是不同表中的鍵。這是一個論壇應(yīng)用程序，簡要說明：c＃從數(shù)據(jù)庫獲取所有論壇并將其存儲在應(yīng)用程序緩存中。在C＃調(diào)用獲取這些論壇和該用戶線程的過程之前，c＃會考慮權(quán)限和一些業(yè)務(wù)邏輯，執(zhí)行一些邏輯過濾“所有論壇”集合的邏輯。超時發(fā)生在數(shù)據(jù)庫而不是應(yīng)用程序本身。對查詢執(zhí)行所有這些邏輯將需要大量內(nèi)部聯(lián)接，而且我不確定100％是否可以在過程內(nèi)完成所有這些操作。我正在使用SQL Server 2000

查看完整描述

3 回答

茅侃侃

TA貢獻(xiàn)1842條經(jīng)驗獲得超21個贊

使用IN運算符編寫查詢時，有一些注意事項，它們可能會影響性能。

首先，大多數(shù)數(shù)據(jù)庫通常在內(nèi)部重寫IN子句以使用OR邏輯連接符。因此col IN ('a','b','c')被重寫為：(COL = 'a') OR (COL = 'b') or (COL = 'c')。假設(shè)您在上有一個索引，則這兩個查詢的執(zhí)行計劃可能等效col。

其次，當(dāng)對可變數(shù)量的參數(shù)使用IN或OR時，每次參數(shù)更改時，都將導(dǎo)致數(shù)據(jù)庫不得不重新解析查詢并重建執(zhí)行計劃。為查詢建立執(zhí)行計劃可能是一個昂貴的步驟。大多數(shù)數(shù)據(jù)庫使用EXACT查詢文本作為鍵來緩存它們運行的查詢的執(zhí)行計劃。如果執(zhí)行類似的查詢，但謂詞中的參數(shù)值不同，則很可能導(dǎo)致數(shù)據(jù)庫花費大量時間來解析和構(gòu)建執(zhí)行計劃。這就是為什么強(qiáng)烈建議將綁定變量作為確保最佳查詢性能的一種方式。

第三，許多數(shù)據(jù)庫對它們可以執(zhí)行的查詢的復(fù)雜性有一個限制-這些限制之一是謂詞中可以包含的邏輯連接詞的數(shù)量。在您的情況下，幾十個值不太可能達(dá)到數(shù)據(jù)庫的內(nèi)置限制，但是如果您希望將數(shù)百或數(shù)千個值傳遞給IN子句，則肯定會發(fā)生。在這種情況下，數(shù)據(jù)庫將簡單地取消查詢請求。

第四，在謂詞中包含IN和OR的查詢不能總是在并行環(huán)境中最佳地重寫。在許多情況下，沒有應(yīng)用并行服務(wù)器優(yōu)化-MSDN對如何優(yōu)化并行查詢進(jìn)行了不錯的介紹。通常，盡管如此，使用UNION ALL運算符的查詢在大多數(shù)數(shù)據(jù)庫中都是微不足道的-并在可能的情況下首選邏輯連接符（例如OR和IN）。

反對回復(fù) 2019-11-28