是否值得為sql插入打開多個數據庫連接

Question

我正在編寫一個與海量數據獲取相關的項目。 目前我正在使用 .NET Framework 4.8 和 Mysql 包來啟動連接並將數據插入數據庫服務器。

我將插入大約 400, 000 行/秒。 我擔心 SQL 連接可能會成為我程序的瓶頸。 我想知道如果我用 sql 創建一個多線程連接並使用消費者隊列插入數據，它會更快，是否值得（優點和缺點）？

在我的直覺中，它會更快，但我不確定它在線程開銷方面可以提供多少性能。 我不是 SQL 專家，所以如果有人能解釋在多個線程上打開多個 SQL 連接的優缺點，那就太好了。

Answer 1

謠言、觀點、傳聞、事實、版本相關的基准、一些個人經驗等……

多線程將提高吞吐量，但有限制：

• 吞吐量被限制在理論限制的一半左右。 （你的“一定百分比”）（這是基於多線程包的基准；我忘記了名字；那是十年前的事了。）
• 多個線程將通過互斥鎖和其他必要的鎖定機制相互競爭。
• 在 5.7 左右，64 個線程是 MySQL 對多線程的限制； 在此之上，吞吐量停滯甚至下降。 （來源：許多 Oracle 基准測試吹噓一個版本比前一個版本好多少。）（同時，每個線程的延遲都達到了頂峰。）
• 如果可能，每個線程都應該批處理數據。

批處理：

• LOAD DATA是一次從單個線程INSERT大量行的最快方法。 但是，如果您包括將文件寫入LOAD的成本，這可能會使其實際上比批量插入慢。
• 批量INSERT緊隨其后。 但是，當它達到某個限制或“收益遞減”時，它會限制在“數百”行。
• 批量插入的速度是每個INSERT查詢插入一行的 10 倍。 所以它（或LOAD DATA ）值得用於高速攝取。 （來源：許多不同的定時測試。）

數據來源：

• 一些數據源必須一次只提供一行（例如，每 N 秒來自車輛的傳感器數據）。這要求某個中間層對數據進行批處理。
• 收集數據的討論：http: //mysql.rjweb.org/doc.php/staging_table

加載數據后會發生什么？ 當然，這不是一個只寫永不讀的表。

• 規范化對於縮小磁盤占用空間很有用； 這最好分批完成。 見 歸一化
• PARTITIONing很少有用，除了最終清除舊數據。 見分區
• 一個巨大的“事實”表很難搜索； 考慮在攝取數據時構建摘要數據：摘要表
• 甚至可以進行上述處理，然后折騰原始數據。 聽起來您每天可能會獲取 1 TB 的數據。