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
Writing on MySQL
Pooled connections with information_schema introspection, EXPLAIN plans and performance_schema-backed monitoring. Where it stops: Agent mode is unavailable, as on every engine but PostgreSQL, SQLite and DuckDB.
With performance_schema off, MySQL metrics are absent not zero
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.
Reading MySQL EXPLAIN FORMAT=JSON as a plan tree
What the plan tree answers on MySQL, and where the surrounding introspection runs out: index figures here are estimates of distinct values.
A MySQL ER diagram is bounded by one database
Every introspection query binds to the connected database, so a reference that crosses schemas simply does not appear as an edge on the diagram.
A MySQL connection URI skips your SSL and timezone settings
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.
Connecting to MySQL in a container, and what the pool honours
Port 3306 with the fixture credentials, the container-network case, and the pool settings that are quietly ignored because the driver model differs.
Stopping a runaway MySQL query is cancellation, not a timeout
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.
Agent plan mode on MySQL drafts; it does not execute
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.