對並行標量 UDF 的支持是合理的功能要求嗎？
標量 UDF 強制執行整體串列計劃，這是相當有據可查的。
鑑於大量行進入管道中必須計算 UDF 的點，為什麼引擎不能在處理器之間分配它們？如果 UDF 中沒有狀態，則順序無關緊要。
有人聲稱 UDF 是一個必須使用游標的黑盒。我可以看到，對於在迭代之間保持某些狀態但似乎應該是可並行化的情況，使用者游標無法在 SP 內並行化。
額外的點來解釋為什麼引擎強制整個計劃是串列的，而不僅僅是 UDF 計算階段。
對並行 UDF 的支持是否是一個合理的請求功能？
UDF 強制執行整體串列計劃是相當有據可查的。
我不確定它是否有據可查。
- 標量 T-SQL 函式可防止計劃中任何地方的並行性。
- 只要不訪問數據庫，標量 CLR 函式就可以並行執行。
- 多語句表值 T-SQL 函式在計劃中強制使用串列區域，該計劃可能在其他地方使用並行性。
- 內聯表值 T-SQL 函式像視圖一樣展開，因此沒有直接影響。
請參閱強制執行並行執行計劃和/或 Craig Freedman 的並行執行展示文稿。
有人聲稱 UDF 是一個黑盒，必須使用游標。
這些說法是不正確的。
額外的點來解釋為什麼引擎強制整個計劃是串列的，而不僅僅是 UDF 計算階段。
我的理解是，目前的限制純粹是某些實施細節的結果。沒有根本原因無法使用並行性執行函式。
具體來說，T-SQL 標量函式在單獨的 T-SQL 上下文中執行，這使正確操作、協調和關閉（尤其是在發生錯誤的情況下）變得非常複雜。
同樣，表變數通常支持並行讀取（但不支持寫入），但表值函式公開的表變數由於特定於實現的原因不能支持並行讀取。恐怕你需要有原始碼訪問權限（以及分享細節的自由）的人來提供權威的答案。
對並行 UDF 的支持是否是一個合理的請求功能？
當然，如果你能做一個足夠強大的案例。我自己的感覺是，所涉及的工作會很廣泛，所以你的提案必須達到一個非常高的標準。例如，提供內聯標量函式的相關（並且更簡單）的請求得到了很好的支持，但多年來一直沒有實現。
您可能想閱讀 Microsoft 論文：
- Froid：關係數據庫中命令式程序的優化(pdf)
…它概述了 Microsoft 希望在 SQL Server 2017 之後的版本中解決 T-SQL 標量函式性能問題的方法。
Froid 的目標是使開發人員能夠在不影響性能的情況下使用 UDF 和過程的抽象。Froid 使用一種新技術來實現這一目標，盡可能將命令式程序自動轉換為等效的關係代數形式。Froid 將命令式程式碼塊建模為關係表達式，並使用 Apply 運算符系統地將它們組合成一個表達式，從而使查詢優化器能夠選擇有效的面向集合的並行查詢計劃。
（強調我的）
內聯標量 T-SQL 函式現在在 SQL Server 2019 中實現。