Either you manage a pool of connections à  la Apache::DBI or you open the connection at the start of each script and close it at the end. In the first of these cases you will have a limited number of connections "waiting" before they are being used, but that is OK: the only cost is some memory. In the second case, you have no "idle" connections, but you will pay the cost of setting up and tearing down a connection each time the script runs.

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.