wait_timeout is how long MySQL lets a connection sit idle before closing it: 8 hours, by default. It's worth knowing about, and for most apps it's worth leaving alone. Here's what it does, tested live.
SET GLOBAL max_connections works right away, and a restart forgets it. SET PERSIST keeps it, with no config file to edit, which is handy in a Docker container. I set it, restarted MySQL, and checked where the value came from.
Three questions tell you if MySQL is near its connection limit: how many now, how many at the worst moment, and who has them. Each is one statement.
MySQL can invent a strong password for an account and show it to you once, so nobody has to think one up. Just look at what it produces before you paste it into a connection string.
MySQL can refuse weak passwords, with a component that's off by default in the Docker image. It takes one statement to turn on, and it's easy to see its rules, or score a password, before you rely on it.
To stop an account signing in, without deleting it or changing its rights or password, lock it. One thing to know first: sessions that are already open carry on working.
In MySQL, an account isn't just a name: it's a name and where it may connect from. Narrow that part, and a stolen password is useless from anywhere else.
MySQL's max_connections limits the whole server, so one app with a runaway pool can lock everyone else out. MAX_USER_CONNECTIONS puts a ceiling on one account, so that its problem stays its own.
Change an app's MySQL password the plain way, and there's a gap between the server's change and the app's. With RETAIN CURRENT PASSWORD, MySQL accepts both for as long as you need, so there's no gap at all.
An app shouldn't be able to change tables, but migrations have to. So they get their own account. To find exactly which rights it needs, I applied a real set of EF Core migrations to an empty database, taking away one right each time.
