druid默认连接池大小并非固定值，而是由一系列配置参数决定。 理解并正确设置这些参数对于应用性能至关重要。 简单的说，它取决于你的应用需求，没有一个放之四海而皆准的“正确”答案。
我曾经参与一个项目，初期数据库连接池配置沿用了旧项目的参数，导致在高并发场景下频繁出现连接耗尽的情况，最终引发应用瘫痪。 当时，Druid 的默认配置并没有满足实际需求。 我们花费了大量时间排查问题，最终才发现是连接池大小设置过小造成的。 那次经历让我深刻认识到，理解并合理配置 Druid 连接池的重要性。
Druid 提供了几个关键参数来控制连接池大小：initialSize、minIdle、maxActive。 initialSize 指定初始化时创建的连接数量；minIdle 定义最小空闲连接数，保证一定数量的连接随时可用；maxActive 则设定连接池最大连接数，限制并发连接数量。 这三个参数的设置需要仔细权衡。
举个例子，假设你的应用预期每秒有 100 个请求，每个请求需要一个数据库连接，并且连接处理时间平均为 10 毫秒。 如果你的 maxActive 设置为 10，那么当并发请求超过 10 时，就会出现连接等待，甚至连接耗尽的情况。 因此，需要根据你的应用预期负载和连接处理时间来估算 maxActive 的值。 通常情况下，我会将 maxActive 设置得比预期最大并发连接数略高一些，留有一定的冗余。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
另一个容易忽视的细节是 minIdle 的设置。 如果 minIdle 设置过低，当应用负载突然增加时，可能需要创建新的连接，这会增加延迟。 反之，如果 minIdle 设置过高，则会浪费数据库连接资源。 理想情况下，minIdle 应该足够满足应用的最低负载需求，避免频繁创建和销毁连接。
此外，validationQuery 参数也至关重要。 它用于定期检查连接是否有效，防止使用失效的连接。 配置一个简单的 SQL 语句，例如 SELECT 1，可以有效避免因连接失效导致的应用异常。 定期验证连接能保证连接池中的连接始终处于可用状态。
最终，配置 Druid 连接池大小是一个迭代优化的过程。 你需要监控连接池的使用情况，例如活跃连接数、等待连接数、连接创建和销毁次数等，根据监控数据调整参数，找到最合适的配置。 记住，没有完美的数值，只有适合你应用的配置。 通过持续的监控和调整，才能确保你的应用拥有最佳的数据库连接性能。
