A common mistake is treating sql.Open as a single database connection. It returns an *sql.DB that manages reusable connections, which may be in use by another goroutine or idle for later operations. section 10.4.2
Tune the pool according to database capacity and request behavior:
- SetMaxOpenConns limits simultaneous database connections; leaving it unlimited can exceed what the database handles. section 10.4.2
- SetMaxIdleConns controls reusable idle connections; increasing it can reduce reconnects during concurrent requests. section 10.4.2
- SetConnMaxIdleTime and SetConnMaxLifetime close connections after configured idle or total lifetimes. section 10.4.2
When the pool is full
With five maximum connections, four ongoing connections leave one slot. A new query reuses an idle connection; without an idle connection, it creates one if a slot remains or waits until one becomes available. section 10.4.2
The same tradeoff appears in Go's HTTP client. Connections are reused, but MaxIdleConnsPerHost defaults to two; repeated parallel requests to one host can therefore cause reconnects and higher latency. section 10.7.1
Use the five-connection diagram to trace idle connections, active connections, available capacity, reuse, creation, and waiting. section 10.4.2








