是否值得为sql插入打开多个数据库连接?

Question

我正在写一个与大量数据获取相关的项目。目前我使用。net Framework 4.8和Mysql包来启动连接并插入数据到数据库服务器。

我将插入大约400000行/秒。我担心SQL连接可能成为我的程序的瓶颈。我想知道，如果我创建一个多线程连接与sql和使用消费者队列插入数据，它会更快，是值得的(利弊)?

在我的直觉中，它会更快，但我不确定它能提供多少性能，就线程的开销而言。我不是SQL专家，所以如果有人能解释一下在多个线程上打开多个连接到SQL的利弊，那就太好了。

Answer 1

谣言、观点、道听途说、事实、版本相关基准、一些个人经验等等……

多线程将提高吞吐量，但有限制:

• 吞吐量上限约为理论限制的一半。(您的"特定百分比")(这是基于多线程包的基准测试;我忘了名字;那是十年前的事了。
• 多个线程将在互斥锁和其他必要的锁定机制上相互竞争。
• 在5.7版本中，64线程是MySQL的多线程限制;超过这个值，吞吐量就会停滞甚至下降。(来源:许多Oracle基准测试吹嘘一个版本比以前好得多)(与此同时，每个线程的延迟时间都在飙升。)
• 如果可能的话，每个线程都应该批处理数据。

配料:

• LOAD DATA是一次从单个线程INSERT大量行的最快方法。但是，如果将写入文件的成本包含在LOAD中，那么它可能会比批量插入更慢。
• BatchedINSERT紧随其后。但它的上限是"100";
• 批处理插入比每个INSERT查询插入一行快10倍。因此，它(或LOAD DATA)值得用于高速摄取。(来源:许多不同的定时测试。)

数据来源:

• 一些数据源必须一次只传递一行(例如，每N秒从车辆上获取的传感器数据)。这需要一些中间层来批处理数据。
• 收集数据的讨论:http://mysql.rjweb.org/doc.php/staging_table

加载数据后会发生什么?这肯定不是一个只写不读的表。

• 规范化对于缩小磁盘占用空间很有用;这是最好分批完成。看到正常化
• PARTITIONing很少有用，除非最终清除旧数据。看到分区
一个巨大的"事实"表很难搜索;考虑建筑总结数据作为你摄取他数据:汇总表
• 甚至可以进行上述处理，然后丢弃原始数据。听起来你可能每天获取1 tb的数据。