[RndTbl] hung mysql transaction locks after a php runtime error?

[Trevor Cordes]

On 2020-08-01 Adam Thompson wrote:
> 
> AFAIK, if you're using local (AF_UNIX) socket connections, MySQL
> still has the lowest connection "cost" of any major database.  Which
> isn't trivial, but should be low enough you can almost ignore it.
> Connections over AF_INET (even to 127.0.0.1) are much more expensive,
> but still pretty cheap.  It'll become a problem at scale, I think, if
> you're establishing hundreds of new connections per second.  Not 100%
> sure. -Adam

Good idea.  I checked and the ini's are set to blank (default) and my
php code specifies it in the connect as "localhost".  However, I can't
definitively find if that triggers php-mysqli to use UNIX or INET...
because the examples to connect to a UNIX socket are
localhost:/path/sock

However... it wouldn't be hard for me to just explicitly make it the
sock on all my deployments, as it's a deploy-level var in my code.

We can (and in the future certainly plan to) get 100's of hits a
second.  I think for now my plan will be to deploy with defaults
and persistence and cross my fingers and check for the email it'll send
me if some lock ever hangs for the 50s...

I'm also curious to see how many real-life transaction deadlocks occur
with all my new transaction usage.  Are deadlocks endemic or uber-rare?
(Assuming non-pathological code.)

Thanks for all the help, MUUGers