在我们的ASP.NET应用程序中，我们实现了一个基于MySQL构建的数据层，并使用Connector/NET来实现实体框架。
这对我们的大多数CRUD操作非常有效，但是当我们运行带有几百条记录的INSERT语句时，它会抛出“Too many connections”异常。
虽然我接受我们正在进行大量单独的读/写调用（我们在每次插入之前查询重复的条目，另外还有一个审计日志，也是为每个插入使用单独的查询写入的）但是不应该连接池处理这个？
此外，在this similar thread中，OP被告知使用使用语句，我完全赞同，在我们的例子中，每个查询 已经包含在使用语句，我假设它是以有效的方式管理连接：即，如果另一个请求已经排队，则不处理它们。
无论如何，connect timeout目前是50，已经非常小了，对吧？将它移动到500没有任何区别，而将它向下移动到10给了我大约50％的插入，然后抛出相同的异常。
因此，假设DbContext的每个实例都包含在 using 语句中，为什么我们会收到“Too many connections”异常？
更新：我们发现问题的根源实际上是由我们的某个存储库在其构造函数中打开数据库连接引起的，即使此连接从未使用过。对不起伙计们，这原来是一只红鲱鱼。谢谢你的建议。
答案 0 :(得分：0)
不完全是您正在寻找的答案......但是：
为什么您没有为所有操作使用相同的连接？
举个例子：
如果您连续执行50次插入，那么使用相同连接的50次查询（每次插入一次）将极大地提高您的系统性能。
答案 1 :(得分：0)
典型插入物的平均执行情况如何？是否有可能在处理前一个插入之前获取新插入（带有所有around-insert子查询）请求的连接？您是否尝试分析/记录DAL插入功能在此重载插入期间的执行情况？通过将部分逻辑从“纯实体查询”移动到触发器（审计日志记录，请参阅How to program a MySQL trigger to insert row into another table?）和存储过程（查询重复项+自身插入），可以大大提高性能（如果这将成为问题） ，因为您将减少往返服务器/更多控制查询的往返次数。
并且，作为最后一个选项，您可以尝试挖掘mysql配置，增加连接限制，默认情况下为100个连接。但是这个想法通常只会推迟搜索DAL中的瓶颈。