MySQL实体提供者：“连接太多”

Question

在我们的ASP.NET应用程序中，我们实现了一个基于MySQL之上的数据层，该数据层使用Connector / NET来实现实体框架。

对于大多数CRUD操作而言，这非常理想，但是当我们运行带有数百条记录的INSERT语句时，它将引发“连接过多”异常。

虽然我接受我们正在进行许多单独的读/写调用（我们在每次插入之前查询重复的条目，再加上一个审计日志，对于每个插入都使用单独的查询来写入审计日志），但是连接不应该游泳池照顾这个？

同样，在这个类似的线程中 ，OP被告知要使用我完全同意的using语句，并且在我们的情况下，每个查询都已经被包装在using语句中，我假设它以有效的方式管理连接： 即 ，不处理他们，如果另一个请求已排队。

而且， connect timeout当前为50，这已经很小了，对吧？ 将其增加到500没什么区别，而将其减少到10则使我在抛出相同异常之前增加了大约50％的插入次数。

因此，鉴于DbContext的每个实例都包装在using语句中，为什么我们会收到“连接过多”异常？

更新：我们发现问题的根源实际上是由我们的一个存储库在其构造函数中打开数据库连接引起的，即使从未使用过此连接。 抱歉，这真是一条红鲱鱼。 感谢您的建议。

Answer 1

并非您要找的答案...但是：

您是否没有为所有操作使用相同的连接的特定原因？

举个例子：

如果您要连续执行50次插入，结果使用相同的连接进行50个查询（每个插入一个），将大大提高系统性能。

Answer 2

一般的插入平均执行情况如何？ 在处理前一个请求之前，是否有机会获得新的插入请求（包括所有插入周围子查询）的连接？ 您是否尝试分析/记录在此繁重的插入负载期间DAL插入功能的执行情况？ 有时，通过将逻辑的一部分从“纯实体查询”转移到触发器（审计日志，请参阅如何对MySQL触发器进行编程以将行插入到另一个表中？ ）和存储过程（可以解决问题），可以大大提高性能（如果这是问题所在）。查询重复项+自行插入），因为您往返服务器的次数将更少，对查询的控制也将更多。

并且，作为最后一个选择，您可以尝试挖掘mysql配置，增加连接数限制，默认情况下为100个连接数。 但是这个想法通常只是推迟在DAL中搜索瓶颈。