Mysql连接池问题：值得吗？

Question

我记得听说mysql中的连接过程与其他RDBMS相比设计得非常快，因此如果启用连接池，使用a library that provides connection pooling（SQLAlchemy）实际上并没有那么多帮助。

有没有人有这方面的经验？

我对启用它是很谨慎的，因为如果某些代码对数据库连接做了某些有状态的事情并且（可能是错误地）不会自行清理，那么通常在关闭连接后会清理的状态而是将传播到后续代码，以获得循环连接。

Answer 1

使用SQLA的连接池时，无需担心连接上的剩余状态，除非您的应用程序正在更改连接范围的选项，如事务隔离级别（通常情况并非如此）。签入时，SQLA的连接池在连接上发出connection.rollback（），以便清除任何事务状态或锁。

MySQL的连接时间可能非常快，特别是如果你在同一台机器上连接unix套接字。如果您确实使用了连接池，那么您还需要确保在一段时间后回收连接，因为MySQL的客户端库将自动关闭空闲超过8小时的连接（在SQLAlchemy中这是pool_recycle选项）。 / p>

通过将池实现从默认的QueuePool更改为NullPool，您可以快速完成连接池与非SQLA应用程序的连接，NullPool是一个实际上不会集合任何内容的池实现 - 它连接和断开连接获取代理连接后再关闭。

Answer 2

即使MySQL本身的连接部分非常光滑，大概仍然存在网络连接（无论是环回还是物理连接）。如果您正在进行批次请求，那么这可能会非常昂贵。它将取决于（通常情况下）你的应用程序究竟在做什么，当然 - 如果你在每个连接上做了很多工作，那么这将占主导地位，你将不会获得很多。

如果有疑问，那么基准测试 - 但我会大体上相信连接池库（至少是一个有信誉的库）应该正常工作并适当地重置。

Answer 3

简短回答：你需要对它进行基准测试。

答案很长：这取决于。 MySQL快速进行连接设置，因此避免这种成本并不是连接池的好理由。你赢了的地方就是如果查询运行很少而且速度很快，因为那时你会看到一个带池的胜利。

另一个担心是应用程序如何处理SQL线程。如果它没有SQL事务，并且不对线程的状态做出任何假设，那么池化将不会成为问题。 OTOH，依赖于关闭线程来丢弃临时表或回滚事务的代码在池化时会遇到很多问题。

Answer 4

连接池加速了这一事实，即每次执行数据库查询时都没有创建java.sql.Connection对象。我将Tomcat连接池用于mysql数据库，用于执行大量查询的Web应用程序，在高用户负载期间，速度明显提高。

Answer 5

我使用Django创建了一个简单的RESTful服务，并使用和不使用连接池对其进行了测试。就我而言，差异非常明显。

在局域网中，没有它，响应时间在1到5秒之间。有了它，不到20毫秒。 结果可能会有所不同，但我正在使用的配置用于MySQL＆amp; Apache服务器是非常标准的低端服务器。

如果您通过互联网提供UI页面，则用户可能无法注意到额外的时间，但在我的情况下这是不可接受的，因此我选择使用该池。希望这会对你有所帮助。