This by no means will be a definitive answer, but I had some tips that were longer than the comments would allow.
That high max execution time concerns me. The root of your problem probably has nothing to do with the number of connections to the DB and more to do with the amount of time these connections are alive.
Here’s a few things to look into:
Admin Heartbeat
You mentioned a large number of editors online at the same time. The Heartbeat API fires every 15 seconds and could write to the DB every time for every user, depending on your settings and the user’s activity.
Check your heartbeat interval and number of revisions stored. I see you already have the autosave interval tuned.
DB Updates triggered
Database writes are some of the most intensive for mysql. The more requests for writes, especially at the same time, the higher the load. If your write queue gets too long it can lead to lingering open connections and eventually it will max out your available connections.
- When you update or publish posts what else happens beyond updating the post data?
- Are you using a caching plugin that purges caches, possibly even transients in the DB?
- Are you using an XML sitemap plugin that regenerates after publishing?
- Are you using an SEO plugin that analyzes content?
- Are you using a link tracker or analyzer?
- All of these things (or many of them) could contribute to a flood of DB writes.
Reduce database load
Get an object cache storage solution in place if you don’t have one already. Redis or Memcache do wonders to reduce load on your database.
Check your options
The autoload column in the options table indicates whether the options will be read from the database on all requests. If this is large, it can lead to longer requests to the database. This is another place object caching can help. This may not contribute to your situation, but it’s worth looking into for performance concerns.