MySQL doesn't have any feature to do what you're describing. That is, MySQL has no FIFO (queue) of connections when you hit max_connections
. All connections get an error if they can't get connected immediately.
The closest related thing built into MySQL is the config variable back_log
, which only configures the limit on the number of outstanding connections. That is, the main MySQL thread takes a small amount of time to check for incoming connections, and these stack up in the listen queue, which is before the socket even completes and before MySQL determines if we've got more than max_connections
threads. In fact, you could get a bunch of outstanding connections in the listen queue even if the server is currently far below max_connections
threads.
http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_back_log
Another option is to add HA-Proxy into the mix, because HA-Proxy does have provide queue feature. Here's a blog that explains this more: http://flavio.tordini.org/a-more-stable-mysql-with-haproxy
Frankly, most sites just increase max_connections
until it can handle your typical spikes in traffic, and from there just try to optimize database activity, so connections are short in duration and therefore you have good throughput. It also helps to code your application to connect as late as possible and disconnect as promptly as possible once all queries are done.
If you have an atypical spike in traffic that exceeds max_connections
, then your application will receive an error indicating that. You should code your app to handle such errors gracefully. That is, display as nicely as you can a message like "We're sorry, our load is too great to handle your request at the moment, please try back in a minute." That's at least better than an abrupt white screen, or a stack trace or something.