事務隔離級別不同執行緒大量寫入
我有很多執行緒將兩個表中的一些數據寫入數據庫。tbl_raw_data和 tbl_parsed_data其中tbl_parsed_data具有****tbl_raw_data的外鍵。
我還需要寫作速度超快。
在檢查改進寫入的選項時（假設閱讀時間非常重要），我的一個朋友告訴我，我需要檢查適合我的邏輯的事務隔離級別。在閱讀了一些關於這個問題的文章後，我了解到這個屬性會影響閱讀。
是否存在影響寫入的事務隔離級別？對於在大量連接上執行的大量執行緒，哪種隔離級別是“最佳”的？
我找錯地方了嗎？
我能做些什麼來改善大量寫作？
我使用 SQL 伺服器，執行緒來自 TomEE 伺服器，該伺服器通過 JDBC 和 JPA (ORM) 寫入通過 HTTP 請求來的數據。
謝謝！
ORM 需要有關第一次寫入的資訊（SCOPE_IDENTITY 等）來完成第二次寫入。這意味著通常在客戶端事務中呼叫 2 個（帶有 OUTPUT 子句）或 3 個數據庫（帶有 SELECT SCOPE_IDENTITY）呼叫。
對隔離級別的任何修改都不會消除這 2 或 3 個呼叫。
如果您想要更高的性能，那麼最好的概念儲存過程在一個數據庫呼叫中對兩個表執行原子寫入（在事務中）。這意味著數據庫呼叫減少了 50% 或 66%
更進一步，您必須確定“超快”的真正含義
例如，您是否應該為事務日誌文件使用 SSD：託管日誌文件的驅動器決定了整體寫入速度，因為預寫日誌記錄。
然後是設計：您使用的是 IDENTITY 列或 GUID 還是 Hibernate 樣式的 nvarchar 鍵？ORM 是否為您設計了數據庫？
影響寫入的唯一隔離級別是 SNAPSHOT（和 READ_COMMITTED_SNAPSHOT）。快照隔離需要行版本控制，行版本控制需要額外的寫入。閱讀了解基於行版本控制的隔離級別。
現在關於問題的“超快”部分：INSERT 的“超快”選項是批量插入路徑。這需要一個能夠理解批量插入的客戶端 API：
IRowsetFastLoad在 OleDB、ODBCsend_row或託管 .NetSqlBulkCopy中，EnableBulkLoad=true對於 JDBC。您不希望“大量執行緒執行大量連接”，您希望一個執行緒在批量 API 模式下執行大量插入。在應用程序中使用生產者-消費者模式將所有應用程序執行緒集中到一個單獨的批量寫入執行緒。