Nine servers, one connection type, different answers
MariaDB, Percona, TiDB, Vitess and five more arrive through the same MySQL connection, and protocol compatibility is not capability compatibility.
8 posts
Pooled connections with information_schema introspection, EXPLAIN plans, performance_schema-backed monitoring and agent mode under a principal verified to hold nothing past SELECT and SHOW VIEW. Where it stops: A transaction a script leaves open is not ended when its pooled connection is released, so it holds its row locks until the connection is reused or the pool closes. The one reliable check reads performance_schema, which is off by default on MariaDB.
MariaDB, Percona, TiDB, Vitess and five more arrive through the same MySQL connection, and protocol compatibility is not capability compatibility.
Cache hit ratio, queries per second and buffer-pool usage are omitted rather than defaulted, and two more figures mean less than their names suggest.
What the plan tree answers on MySQL, and where the surrounding introspection runs out: index figures here are estimates of distinct values.
Every introspection query binds to the connected database, so a reference that crosses schemas simply does not appear as an edge on the diagram.
Supplying a connection string takes a different branch entirely, so the SSL panel, the timezone and cloud detection stop applying and must live in the URI.
Port 3306 with the fixture credentials, the container-network case, and the pool settings that are quietly ignored because the driver model differs.
No server-side statement timeout is wired into the pool, so nothing kills a long query on its own and cancellation is an explicit act with a caveat.
The tool-using run ends engine-unsupported here, so the useful post is what plan mode does instead: read the real schema and hand a statement to a person.
We use cookies to analyse site traffic and improve your experience. See our Privacy Policy for details.