是否值得为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 的数据。