You don't mention whether it's running under mod_perl or FastCGI, where DBI's FAQ might answer your question (more for mod_perl than FastCGI). If it's really a CGI application that gets executed when requested, and is otherwise not loaded/running, then you'll have to switch to mod_perl or FastCGI or something similar, where your DBI connections can be cached.

Though, I have to admit, I'm a bit confused by your wording. If you don't reuse connections, you never have to worry about timing out - since you'd be creating a new connection each time your CGI code was executed.

I'm afraid there is no simple way to share database connections between different (plain) CGI processes. You could use something like DBI::ProxyServer or POE::Component::EasyDBI, for example, to implement a stand-alone connection pool manager for your CGI processes, but I wouldn't recommend it. In persistent environments like FastCGI or mod_perl, however, it is possible (and actually quite easy) to reuse DBI database handles on a per process basis. Take a look at Apache::DBI for inspiration.

that way it won't have unused connections waiting to time out or anything that could cause bad things to happen

I'm afraid chances are in general that more bad things will happen when you try to use shared DB connections with CGI scripts ;)   Anyhow, if you really need to do so (for performance reasons), you might want to look into connect_cached, or Apache::DBI (when using mod_perl).  But in this case be particularly careful with forking in combination with persistent DB connections (see InactiveDestroy).

Also note that "normal" CGI scripts start up a new process for every HTTP request, but you'd rather want persistent request handlers that allow to keep a DB connection open — as offered by FastCGI or mod_perl.  Otherwise, you'd have to have a separate "connection broker" (a persistently running process) that you connect to from the CGI script (e.g. via a socket) in order to delegate the DB query to a free DB handle from a pool of handles managed by the broker (in the hopes that the communication overhead with the broker is less than the overhead resulting from simply opening a new DB connection every time...)

Having different (or even the same) scripts use the same connection simultaneously is much more likely to cause problems.

Anyhow, a modern database server allows hundreds (if not thousands) of simultaneous connections. The manual of MySQL 5.1 says:

The maximum number of connections MySQL can support depends on the quality of the thread library on a given platform, the amount of RAM available, how much RAM is used for each connection, the workload from each connection, and the desired response time. Linux or Solaris should be able to support at 500–1000 simultaneous connections routinely and as many as 10,000 connections if you have many gigabytes of RAM available and the workload from each is low or the response time target undemanding. Windows is limited to (open tables × 2 + open connections) < 2048 due to the Posix compatibility layer used on that platform.

It seems to me you want a connection pooler, which is a program that (at startup) pre-prepares a smallish pool of connections. Programs request a connection from the pool, and immediately after db-access relinquish the connection back into the pool.

A popular and light-weight connection pooler for the PostgreSQL database is PgBouncer, from the skype developers.

PgBouncer site / manual

and its pgfoundry repository

Sorry to everyone for the confusing post. I have two files on my server which each makes their own connection to my MySQL server. I have never done something to this scale before and so I don't know what would be the best approach to handling database connections like this. As for what I am using I think my server is using mod_perl because I don't have FastCGI installed.