SSIS 與 T-SQL 連接性能，同一伺服器上的差異數據庫
我們正在研究 SSIS Lookup 和 T-SQL Join 之間的性能差異。我們要連接兩個表；表在同一個 SQL 伺服器實例，不同的數據庫中。
我懷疑對於小表連接，差異很小或可以忽略不計。在這種情況下，我們的團隊更喜歡 T-SQL，比編寫圖表更容易編寫程式碼/編寫腳本。此外，從 DevOps 的角度來看，我們可以在 DB 項目中編譯/建構腳本；不幸的是，SSIS 無法正確編譯 T-SQL，我可以在 SSIS Execute SQL 語句中編寫“testabcd”，並且該項目仍將建構/編譯。
但是，對於需要更長時間處理的大量行，什麼更快？具有索引和統計資訊的 T-SQL，還是全部在記憶體中執行的 SSIS？
我以不同的觀點閱讀了這些文章，團隊正在努力達成共識。
https://derekdb.wordpress.com/2012/03/13/ssis-lookup-or-t-sql-join/ http://www.sqlservercentral.com/blogs/jamesserra/2011/08/29/when-to-use-t_2D00_sql-or-ssis-for-etl/
假設，T-SQL 引擎和 SSIS 提供相同的硬體：CPU 和記憶體。鑑於相同的規格，我想從內部算法的角度了解性能速度。
給定相同的規格，想知道性能
如果您的數據位於單個 SQL Server 實例上，則 TSQL 聯接應始終比 SSIS 查找快。這不是很接近。TSQL 查詢將利用索引和統計資訊以及基於成本的查詢優化器。連接將在 SQL Server 實例內部執行，它不僅效率更高，而且比 SSIS 管道擁有更多的記憶體和磁碟資源。
SSIS 查找主要用於目標端查找、異構數據方案以及沒有查詢處理引擎的源（如平面文件）。
此外，當您的數據源是單個 SQL Server 實例，而您的目標是單個（可能不同）SQL Server 實例時，我個人幾乎不會使用任何SSIS 數據流轉換。相反，始終使用源系統 SQL 進行提取端轉換，並使用階段和合併進行目標端轉換。