將數據寫入 SQL 數據庫的最大瓶頸（時間）是什麼？
我正在執行一個 ETL 程序，它將大約 200 萬行寫入 SQL Server 數據庫。
我正在嘗試優化純插入所需的時間（我猜更新是另一回事）。
我想知道對於 SQL 數據庫的基本插入，最大的瓶頸是什麼，或者減少時間的最佳方法。
我的意思是，第一件事可能是數據的大小，對吧？行數、列數和每列中的數據大小。其中一些可能無法最小化，每行的 KB/ 佔用空間是可以優化的一件事，對吧？
還有什麼可以優化的或者是最大的因素？是傳輸介質嗎？我的意思是，寫入同一台電腦上的數據庫與通過 Web 連接寫入（即健壯、快速且 ping 為 1 毫秒？）之間有多大差異。
最後 — 為什麼到數據庫的多個並行連接似乎加快了程序到一個點？我的意思是，當我有 20 個連接以循環方式插入時，它比一個寫入所有數據的連接快 6-7 倍。我很好奇這是為什麼。
現在我有 220 萬行，總計 2.7 GB。這是每行 1.23 kb。
現在使用 14 個連接一次插入 1000 行（1.23 MB）需要 6.7 秒。這是每秒 10.66 行的蝸牛節奏。即使假設 1 個連接也一樣快（它不是），最多 150 行/秒，這也不是完全“快”。我正在編寫一個超快速、強大的 Web 連接 b/c 我們不能在與數據倉庫相同的空間上擁有 ETL 過程。
那麼..我如何在這裡優化速度？
一次 1000 行的原因是因為數據來自 1000 頁 - 但目前優化解析是一個單獨的問題。
我確實有一個我相信的主索引，但沒有什麼太昂貴的。現在我只是在做蒙地卡羅之類的測試（嘗試一下，看看有什麼用），但我需要一些更專注的東西。
您需要閱讀：
- 數據載入性能指南
- 如何分析 SQL Server 性能
- 使用 BULK INSERT 或 OPENROWSET(BULK…) (SQL Server) 導入批量數據
- bcp.exe
- 使用分區切換高效傳輸數據
- 可以最少記錄的操作
- 我們使用 SSIS 在 30 分鐘內載入了 1TB，您也可以
- SqlBulkCopy 類
- SSIS OleDB 目的地
- 執行大容量複製操作（對於 OleDB 和 ODBC 範例）
您必須閱讀每個連結。真的。簡而言之，高效載入必須使用批量插入並實現最少的日誌記錄。SSIS 是迄今為止更好的工具，但您也可以通過程式方式實現這一點。OleDB 是最好的，但如果需要，SqlClient (C#) 也可以。行大小、網路速度等不太可能是您關心的問題，但您應該始終衡量（連結的文章將教您如何衡量）。載入性能應該與現有的數據庫大小完全正交，如果載入速度隨著數據庫大小的增加而降低，那麼您一定是做錯了。
最後 — 為什麼到數據庫的多個並行連接似乎加快了程序到一個點？我的意思是，當我有 20 個連接以循環方式插入時，它比一個寫入所有數據的連接快 6-7 倍。我很好奇這是為什麼。
由於缺乏任何調查和測量，我會猜測。但很可能你現在被送出刷新率阻塞：每次你送出 SQL 都必須停止並等待日誌寫入磁碟。如果您沒有明確地開始事務，那麼每個語句都必須停止並等待。添加更多的載入器會導致更好的日誌使用率，日誌會同時送出給 20 個寫入者。閱讀什麼是 LSN：日誌序列號。