SQL：速度考慮因素：乘以0/1與條件操作

以下查詢之間是否存在顯着的速度差異？SQL：速度考慮因素：乘以0/1與條件操作

- SELECT value * coeff from Table 

- SELECT CASE WHEN coeff = 0 THEN 0 ELSE value END FROM Table

我知道我可以只是嘗試&看到，但我相信你將有有趣的評論作出關於各種數據庫引擎將如何處理，以及事情的幾個測試我會做會想念。

來源

2012-05-03 Skippy Fastol

小心你在這裏測量。考慮到你有一個網絡協議到最上面的應用程序，速度更慢可能會導致更多的CPU負載。 – TomTom

@ hvd：對不起，我在查詢中犯了一個錯誤。固定。（你理解了這個想法） –

@CodeByMoonlight - 根據問題標題 – MatBailie

不會有任何顯着的速度差異。

在最低級別，您需要將兩個值加載到CPU中的寄存器中。那麼，這種差異大致...

Load coeff into register1 
Load value into register2 
If register1 is not 0, skip the next operation 
Load 0 into register2 
Return value in register2

Load coeff into register1 
Load value into register2 
register2 = register1 * register2 
Return value in register2

二是始終爲4點的操作。當coef非零時，第一個是5次操作。

但是第一個版本的操作非常簡單。第二次乘法將更加密集。據我所知，0或1的整數乘法仍然和你一樣快。但是，如果VALUE是一個浮點數，它將更加密集。

（這是所有從基本操作知識，沒有任何專業知識。）

這一切說，然而，差別會比從磁盤加載數據要少得多，或通過tcp/ip傳輸。

您應該運行一個分析器並測量每個CPU使用的CPU週期。不是所花的時間。你可能會發現你使用的CPU比其他版本少一點。而且總時間幾乎沒有差別。

來源

2012-05-03 09:30:06 MatBailie

一個完全不同的可能性是SQL引擎翻譯它例如，在讀取任何行之前，例如，由於SELECT FOR FROM表WHERE coeff = 0 UNION ALL SELECT值FROM表WHERE coeff <> 0'，例如因爲coeff上的索引。在這種情況下，你的答案並不真正起作用。 – hvd

@ hvd - 它永遠不會那樣做。你可能以這種方式重構代碼，但我從來沒有經歷過優化器自己做這件事。這只是一個過於狹窄的優化，而剩下的就是程序員。 – MatBailie

「我從來沒有經歷過這種優化器本身」並不意味着「它永遠不會這樣做」。當這些表足夠大時（或者，你真的不應該在乎，正如你也注意到的那樣），將表設置爲分區視圖可能是有意義的，'coeff'作爲分區列，如果SQL Server沒有在檢查約束'coeff = 0'的分區表中優化'WHEN coeff = 0'，我會感到驚訝。 – hvd

乘法和大小寫列之間的結果數據類型可能有所不同。

試試這個

CREATE TABLE #Tmp (value DECIMAL(19, 2), coeff BIT) 

INSERT #Tmp SELECT 15, 1 
INSERT #Tmp SELECT 16, 0 

SELECT value * coeff AS final_value_mult 
     , CASE WHEN coeff = 0 THEN 0 ELSE value END AS final_value_case 
INTO aaa 
FROM #Tmp 

--DROP TABLE aaa, #Tmp

然後腳本表aaa在SSMS

CREATE TABLE [dbo].[aaa](
    [final_value_mult] [decimal](38, 4) NULL, 
    [final_value_case] [decimal](19, 2) NULL 
) ON [PRIMARY]

顯然乘法升級精度/的value數據類型的規模。 CASE對此類意外結果的抵抗力要強大得多。

來源

2012-05-03 11:33:32 wqw

SQL：速度考慮因素：乘以0/1與條件操作

回答

相關問題