How to Monitor a MySQL Database for Performance Issues
%203.png&w=256&q=75){kind=small}
Start With SHOW PROCESSLIST
Run mysql -u root -p -e "SHOW FULL PROCESSLIST;" and you get a live snapshot of every connection to the server: the user, the host it's connecting from, the database it's touching, the command it's executing, and two columns that matter most when something feels slow — Time and State. Time shows how many seconds a query has been in its current state; a query that's been running for 40 seconds when everything else finishes in milliseconds is your problem, full stop. State tells you what MariaDB is actually doing while it waits — "Sending data" usually means a large scan or join is grinding through rows, "Copying to tmp table" means a query needs a temporary table it probably shouldn't, and "Locked" means it's queued behind another transaction.
A long wall of connections sitting in the Sleep state doing nothing isn't a query performance problem at all — it almost always means the application or connection pool is opening connections and never closing them, which eventually exhausts max_connections regardless of how fast your queries run.
Enable And Read The Slow Query Log
Set slow_query_log = 1, long_query_time = 2, and slow_query_log_file in /etc/mysql/mariadb.conf.d/50-server.cnf, then restart MariaDB. From that point on, any query that takes longer than two seconds gets written to the log with its execution time, rows examined, and rows sent. The log itself is not something you want to read line by line in production — that's what mysqldumpslow is for. It's the tool that ships with MariaDB specifically to summarize a slow log by query pattern, grouping near-identical queries — different WHERE values, same shape — so you see which single query is responsible for the most cumulative time, not just which single execution was slowest. Running it sorted by total time almost always points straight at the query worth fixing first.
Key Status Counters To Watch
Four counters answer most "is the database okay" questions without any log parsing. Threads_connected tells you how many connections are open right now, which you compare against max_connections to see how close you are to exhaustion. Slow_queries is a running counter of everything that crossed long_query_time since the server started, so a fast-climbing number confirms the slow log is worth reading. Questions counts total statements executed and, watched over a few minutes, gives you a rough queries-per-second figure — useful for spotting a traffic spike that's dragging response times down with it. Aborted_connects climbing steadily points at connection problems: wrong credentials, a firewall blocking the app server, or max_connections being hit and MariaDB refusing new sessions. Table_locks_waited, when it's nonzero and growing, means queries are queuing behind table-level locks — a strong signal that a table using MyISAM or a poorly indexed InnoDB table is creating contention under concurrent writes.
Checking The InnoDB Buffer Pool
For anything past "is a query slow," SHOW ENGINE INNODB STATUS\G is the deepest diagnostic MariaDB exposes without external tooling. It dumps the current state of the InnoDB engine — active transactions, lock waits, the buffer pool hit ratio, pending I/O, and deadlock history if one occurred recently. The output is dense, but the section worth checking first under load is the buffer pool and memory summary, since that's where a mis-sized cache shows up as a real number rather than a guess. The setting that decides most of this outcome is innodb_buffer_pool_size — MariaDB uses it to cache table and index data in memory so reads don't hit disk. As a rule of thumb, size it to roughly 60-70% of available RAM on a server dedicated to the database, and noticeably less if the same box is also running PHP-FPM, Nginx, and application code. A buffer pool that's too small for your working data set means MariaDB constantly evicts pages it needs again seconds later, turning what should be memory reads into disk reads — and that shows up everywhere as generic slowness long before anyone thinks to check this one setting.
Automating Checks Without A GUI
You don't need a persistent dashboard open to keep an eye on any of this. mysqladmin status gives you a single-line summary — uptime, queries per second, threads connected, slow queries — in a format that's trivial to pipe into a cron job or a monitoring script. mysqladmin extended-status dumps every counter MariaDB tracks in one shot, which is the scriptable equivalent of running dozens of SHOW GLOBAL STATUS queries by hand. If you want a live, continuously refreshing view without opening a GUI, mytop is a real, installable top-like tool for MySQL and MariaDB that shows active queries, their runtime, and per-thread status updating every few seconds — genuinely useful when you're watching a server in real time during a deploy or a traffic spike rather than reconstructing what happened afterward from a log.
Putting Metrics In Context
CloudStick's Visual Database Manager, available on every plan, is where you'd actually create the database and user for a new project, set permissions, and turn on scheduled backups — all without touching a command line or installing phpMyAdmin. That's the right tool for the administrative side of running MariaDB. But it was never built to be a query profiler, and it doesn't try to be one — diagnosing why a specific query is slow, reading SHOW ENGINE INNODB STATUS, or sizing the buffer pool for a working data set is a level of detail no dashboard abstracts away, because the answer depends on your schema, your indexes, and your actual traffic pattern. The practical workflow is to use the Visual Database Manager for setup and backups, and reach for the command-line techniques above the moment a query — not the server itself — is what's actually slow. If you haven't looked at SHOW FULL PROCESSLIST on a production database in the last month, that's the fastest five-minute check to run next.
