MySQL连接合理connectionTimeout配置咨询及Hikari连接池默认值分析

Great question—let’s break this down step by step, since connectionTimeout is a critical HikariCP setting that’s easy to overlook without context. First, a quick clarification: this value defines the maximum time (in milliseconds) HikariCP will wait for an available connection in the pool before throwing a SQLException. The default 30,000ms (30 seconds) is intentional, but whether it’s "too long" depends entirely on your use case.

Is 30 seconds too long? #

For user-facing web applications: Absolutely. Most users will abandon a request if it takes more than 5 seconds to load—waiting 30 seconds is a terrible UX, and you’ll likely see high bounce rates or frustrated users. In this context, 30 seconds is way too long.

But for background, non-real-time tasks (like batch imports, nightly reports, or async job processing)? 30 seconds might be perfectly reasonable, or even too short. These tasks don’t have an end user waiting, so prioritizing task completion over speed makes sense.

Why is 30 seconds the default? #

HikariCP’s default values are designed to be conservative and work across a wide range of scenarios. The maintainers chose 30 seconds because:

• It accounts for temporary blips: A database might briefly lock up, or a sudden traffic spike might exhaust the pool temporarily. A longer timeout gives the system time to recover instead of immediately failing.
• It accommodates legacy or under-provisioned systems: Not everyone runs a perfectly tuned database or has a properly sized connection pool. The default gives these systems a fighting chance instead of crashing immediately.
• It aligns with common database timeout settings: Many databases have their own connection timeouts that are 30 seconds or longer, so HikariCP’s default matches that to avoid mismatched timeout behaviors.

Who would wait 30 seconds for a connection? #

As mentioned earlier, batch processing jobs, cron tasks, and other backend workloads are the main candidates. For example:

• A nightly job that syncs data between systems doesn’t care if it waits 30 seconds to get a connection—it just needs to finish by morning.
• A report generation tool that runs once a week can tolerate waiting because there’s no user sitting in front of it.

For these use cases, failing fast isn’t desirable—you’d rather the job wait and complete than fail and require manual intervention.

Production environment configuration best practices #

The right connectionTimeout depends on your specific workload, but here are some guidelines:

1. For real-time user-facing apps: #

Set it between 1,000ms (1 second) and 5,000ms (5 seconds). This balances:

• A reasonable user experience (users won’t wait forever)
• Enough time to handle transient pool shortages (e.g., a sudden burst of traffic that the pool can handle once connections are freed up)
• Faster failure detection: If your pool is consistently exhausted, a short timeout will alert you to the problem (via error logs or metrics) sooner, rather than letting requests hang for 30 seconds.

Example configuration:

hikari.connectionTimeout=5000

2. For backend/non-real-time tasks: #

You can safely set it to 10,000ms (10 seconds) to 30,000ms (30 seconds). If your tasks are even more tolerant (like long-running batch jobs), you could go higher, but avoid setting it to an extremely high value (e.g., 5 minutes) unless you’re sure—unlimited timeouts can hide underlying issues (like a leaked connection or misconfigured pool).

3. Always pair with proper pool sizing #

No amount of timeout tuning will fix a pool that’s too small. Make sure your maximumPoolSize is set to a value that matches your database’s capacity (most databases handle 10-100 connections well, depending on resources). Monitor pool metrics like activeConnections, idleConnections, and pendingConnections to adjust sizing over time.

4. Use monitoring to validate #

Track how often your application hits the connectionTimeout limit. If you’re seeing frequent timeouts:

• First, check if your pool is undersized or if connections are being leaked (use HikariCP’s built-in metrics or tools like Micrometer to track this).
• If the pool is sized correctly, consider if your database is under load (high CPU, slow queries) and address those issues before increasing the timeout.

内容的提问来源于stack exchange，提问作者membersound