內加入Vs的標量函數

以下哪個查詢比較好...這只是一個例子，有很多情況，在這裏我要顯示的用戶名，而不是用戶名內加入Vs的標量函數

Select EmailDate, B.EmployeeName as [UserName], EmailSubject 
    from Trn_Misc_Email as A 
     inner join 
     Mst_Users as B on A.CreatedUserID = B.EmployeeLoginName

或

Select EmailDate, GetUserName(CreatedUserID) as [UserName], EmailSubject 
    from Trn_Misc_Email

如果在使用First沒有性能上的好處，我寧願使用第二...我將有大約2000條記錄用戶表和100K記錄電子郵件表...

謝謝

來源

2010-09-01 The King

你有沒有試過這個？ – 2010-09-01 09:25:13

一個很好的問題，極大地想着SQL性能等

從一個純粹的SQL點首先是更好的。在第一條語句中，它能夠通過連接在單個批處理命令中執行所有操作。在第二種情況下，對於trn_misc_email中的每一行，它都必須運行單獨的BATCH選擇來獲取用戶名。這可能會導致現在或未來的性能問題

對於任何參與項目的人來說，讀者也可以看到發生了什麼。如果你有第二個，那麼你就必須去看看這個函數（我猜這就是它）來找出它在做什麼。

所以現實中有兩個原因使用第一個原因。

來源

2010-09-01 09:29:46

內聯SQL JOIN通常會是better than the scalar UDF，因爲它可以更好地優化。

雖然一定要使用SQL事件探查器來查看兩個版本的成本，但在測試它時， SET STATISTICS IO ON不會在其數字中報告標量UDF的成本，這將使標量UDF版本看起來比實際更好。

來源

2010-09-01 09:29:55

您是否有任何參考資料可幫助我理解執行計劃和統計信息 – 2010-09-01 09:56:35

@The King - 請參閱此免費電子書[「Grant解析SQL Server執行計劃」]（http：//downloads.red-gate。 com/ebooks/HighPerformanceSQL_ebook.zip） – 2010-09-01 10:21:49

爲了幫助您更好地瞭解SQL Server中使用Managment工作室的技巧，您可以使用Display Estimated execution plan來評估性能。它顯示了索引和聯接如何工作，您可以選擇使用它的最佳方式。

此外，您可以使用DTA（數據庫引擎優化顧問）獲取更多信息和優化。

來源

2010-09-01 09:32:56

在我看來，標量UDF只是作爲一個黑盒子而已。 – 2010-09-01 09:34:02

您是否有任何參考資料可幫助我理解執行計劃和統計信息。 – 2010-09-01 09:51:51

@馬丁史密斯，不，執行計劃清楚地顯示了所有的步驟以及作爲成本發生的事情......您可以自己嘗試。再加上一個標量UDF緩存執行計劃，以便在下次運行中優化執行 – 2010-09-01 10:00:34

標量UDF是非常緩慢的，but the inline ones are much faster, typically as fast as joins and subqueries

順便說一句，你用查詢函數調用相當於一個外連接，而不是內部之一。

來源

2010-09-01 13:08:19

內加入Vs的標量函數

回答

相關問題