MySQL High CPU Usage: Step-by-Step Diagnosis

The symptoms arrive together: the website slows to a crawl, top shows mysqld or mariadbd at the head of the list, and sometimes the application reports "Too many connections". Whether it is MySQL high CPU usage or MariaDB high CPU, the cause is rarely a server that is too small. Far more often a handful of queries do much more work than they should, and everything else queues behind them. This guide walks through the diagnosis on current releases such as MySQL 8.4 and MariaDB 11, from the first live look to a lasting fix.

Step 1: see what is behind MySQL high CPU usage right now

Connect with the command-line client (on MariaDB it is called mariadb) and run SHOW FULL PROCESSLIST. Each row is a connection: how long its current statement has been running, its state and the complete query text. Patterns stand out quickly:

• Dozens of copies of the same query, each running for seconds: one expensive query hit by normal traffic.
• Many connections in the Sleep state: the application opens connections and does not close them, or its pool is too large.
• States such as "Waiting for table metadata lock": a schema change or a long transaction is blocking everyone else.
• Sorting and temporary-table states on many rows: grouping or ordering without a suitable index.

Two status counters complete the picture. Threads_running shows how many queries are executing at this moment, and Max_used_connections the peak since the last restart. A server with a few CPU cores and dozens of running threads is overloaded by queries, not by visitors.

Step 2: turn on the MySQL slow query log

A live snapshot shows the crisis; the MySQL slow query log shows the pattern. Enable it by setting slow_query_log to ON with a long_query_time of about one second to start, then lower the threshold once the worst offenders are fixed. Both can be changed at runtime and made permanent in the server's configuration file. MariaDB uses the same variable names and explains the options in its slow query log overview.

Leave the log running through a few representative busy days, then summarize it. mysqldumpslow, or mariadb-dumpslow on MariaDB, groups similar statements together, and pt-query-digest from Percona Toolkit gives a more detailed ranking. Sort by total time, not by the single slowest query: a statement that takes 0.2 seconds but runs on every page view costs far more than a nightly report.

Step 3: fix the queries that matter

For each query at the top of the list, run EXPLAIN and read what the optimizer plans to do. The usual slow query fix is one of these:

• A missing or unsuitable index. A full table scan, shown as type ALL, over a large table where a composite index on the filtered and sorted columns would find the rows directly.
• A function on an indexed column, such as wrapping a timestamp column in a date function inside the WHERE clause, which stops the index from being used. Rewriting the condition as a range fixes it.
• Leading wildcards in LIKE searches, which no ordinary index can help. A full-text index or a search service is the real fix.
• The same small query repeated hundreds of times per page, typical of plugins and application loops, better solved with caching in the application.

Test index changes on a copy of the database first. Every index speeds up some reads but adds work to every insert and update, and building an index on a very large table can slow it while the build runs.

Why "Too many connections" is usually a symptom

The error means every allowed connection is in use. The default max_connections in both MySQL and MariaDB is 151, and raising it is tempting. Each connection needs memory, though, and more simultaneous queries on the same CPU cores only make each one slower. Look for the cause of too many connections instead:

• Slow queries holding connections open, which leads back to Step 3.
• More PHP-FPM workers or application threads than the database can serve at once. The web tier should be sized so its peak fits within max_connections, with room left for administration.
• Idle connections kept open for hours by persistent connections or an oversized pool, controlled by wait_timeout and the application's pool settings.

Configuration checks and MariaDB performance tuning

Once the queries are under control, check the settings that decide how hard the database server has to work. The InnoDB buffer pool should hold the data that is used regularly, so reads come from memory rather than disk. Temporary tables that spill to disk show up in the Created_tmp_disk_tables counter. These checks are the core of a MySQL and MariaDB performance review. The query cache is not a fix: MySQL 8 removed it, and MariaDB ships with it disabled because it becomes a point of contention on busy servers. For MariaDB performance tuning on servers with many short connections, the thread pool is worth a look. And if you still run MySQL 8.0, note that Oracle ended its support in April 2026; 8.4 is the long-term release most 8.0 servers move to, and an upgrade is a good moment to recheck query plans.

Frequently asked questions: mysql high cpu usage

Is high CPU always a database problem?

No. If mysqld or mariadbd is not near the top of the process list, look at PHP, the web server or a backup job instead. The database is the likely culprit when its process dominates and the process list shows queries piling up.

Should I restart MySQL when the CPU is maxed out?

A restart clears the queue for a moment, but the same queries return with the traffic, and a restart also empties the buffer pool, so the server is slower until it warms up again. Save the output of SHOW FULL PROCESSLIST first, so the evidence is not lost.

Can I kill a long-running query safely?

KILL QUERY with the connection ID from the process list stops the statement and keeps the connection open, while KILL ends the connection. Stopping a large write can take a while because its changes are rolled back, and it does not fix the cause, so note the query before you kill it.

If a database in Los Angeles or anywhere else keeps running hot, our MySQL and MariaDB database optimization service reviews the slow query log, indexes and configuration, and most of the elapsed time goes into collecting a slow log over a few busy days rather than into the changes themselves. When the web server is the other half of the problem, see our Apache web server optimization service. Contact us with your database version and a description of when the slowdowns happen.