MySQL performance tuning is the work of making a slow or overloaded MySQL database fast again: finding the queries and settings that waste time, fixing them, and proving the result in real numbers instead of promises.
A slow database rarely announces itself. It shows up as a page that used to be instant and now spins, a report that times out at month-end, a server pinned at 100% CPU that your host keeps telling you to upsize. Upsizing buys a few weeks and a bigger bill. The real cause is almost always a handful of queries doing far more work than they should, an index that was never created, or a configuration left at the defaults from the day it was installed. That is usually the week someone goes looking for a person who does exactly this, and the week I get the call.
What does MySQL performance tuning actually cover?
Most projects are one of these, named in your own terms rather than mine.
The query that got slow. A page that loaded instantly at ten thousand rows crawls at ten million. I find the queries doing the damage with the slow query log and EXPLAIN, rewrite them, and add the indexes MySQL needs to answer fast, then measure so the improvement is a number you can see.
The server at 100% CPU. Your host says buy a bigger instance. Usually the real cause is a few queries scanning whole tables because an index is missing, or running far more often than anyone realised. I find them and fix the cause, so you are not renting your way around a problem month after month.
The database that falls over under load. Fine on a normal day, then a sale or a busy Monday brings it down. I look at locking, connection limits, and the queries that pile up under pressure, and make the system hold instead of topple.
The configuration nobody ever touched. MySQL installed years ago, still running on defaults sized for a laptop. Buffer pool, connections, and the settings that actually matter tuned to your real workload, not to a generic template.
The audit before it becomes a fire. You are not down yet, but it is getting slower and you want to know what is coming. A performance audit finds the queries and the design that will break first, ordered by risk, so you fix them on your schedule instead of at 2am.
If you want the full method before we talk, my guide to MySQL performance tuning walks through how it is done. And if the real problem turns out to be the data model or a migration rather than raw speed, that is database consulting, a related but different job.
How does a performance engagement work?
First, a thirty-minute call. You tell me what is actually wrong: the slow page, the CPU alarm, the report that times out. I tell you honestly whether it is a database problem at all, because sometimes it is not, and roughly what fixing it would take. Free, usually this week.
Then I measure the real thing. Not a questionnaire. Your actual slow query log, your actual EXPLAIN output, your actual server metrics. I find where the time truly goes, because the query everyone blames is often not the one costing you.
Then the fixes get made. I rewrite the queries, add or repair the indexes, and tune the configuration myself, or I guide your developers through the parts that touch your code. Either way you watch it happen, you do not just receive a document.
Then we prove it worked. Every change is measured against where you started, so an improvement is a number, not an adjective. You get a plain-language write-up of what changed and why, so the next person who touches the database is not starting blind.
What you get
A faster database you can measure. Before-and-after numbers on the queries and the load that mattered, not a vague promise that things are optimised now.
The queries and indexes fixed at the source. The actual cause removed, so the speed holds instead of drifting back in a month.
A configuration tuned to your workload. MySQL set up for how your application really behaves, not for a default that assumed a machine you stopped using years ago.
A written record. Plain-language documentation of what was done and the reasoning, so your team can keep the database healthy without me.
Is MySQL performance tuning right for you?
A good fit if:
- Your application is slow and you suspect, or have been told, the database is the cause
- Your MySQL server runs hot on CPU and upsizing has only bought you time
- Something falls over under load and you need it to hold
- You want an audit before a busy season, not a rescue during one
- You would rather fix the cause once than keep paying for a bigger instance every quarter
Not a fit if:
- Your application is slow for reasons that are not the database, I will tell you on the first call if that is what I see
- You want a long document of recommendations nobody will action, I fix things or guide a team that will
- You are shopping only for the cheapest hourly rate, careful database work is not where to save money, because the mistakes are expensive and quiet
- Your project is 3D games, casino software, adult content, or adversarial scraping
Frequently asked questions
How do you find what's making MySQL slow?
I measure before I touch anything. The slow query log and EXPLAIN show which queries actually cost the time, and server metrics show whether the pressure is CPU, memory, disk, or locking. Guessing is how people spend a weekend optimising the wrong query. I find the real ones first, then fix those.
My MySQL server is at 100% CPU, what causes that?
Almost always a small number of queries running far more often, or doing far more work, than anyone realises: a missing index turning a lookup into a full table scan, a query stuck inside a loop, a report that reads the whole table every time. Adding CPU hides it for a few weeks. Finding and fixing those queries removes the cause, usually for a fraction of the cost of a bigger server.
Can you speed things up without changing our application code?
Often, yes. A lot of the gain lives in indexes and configuration, which sit outside your application entirely. When a query itself has to change, I rewrite it or show your developers the exact change, and I tell you up front which fixes need a code deploy and which do not.
Do you tune MySQL 5.7 and MySQL 8, and managed databases like RDS?
Yes to all of them. MySQL 5.7 and 8, MariaDB, and the managed versions on AWS RDS, Google Cloud SQL, and Azure. On a managed database you lose some server-level control, but most of the real wins, the queries and the indexes, are fully in your hands no matter where it runs.
How do I know the tuning actually worked?
Because I show you the number. Every change is measured against where you started: query time before and after, CPU under the same load, the report that went from forty seconds to under one. If a change does not move a number that matters, it does not ship. You get a plain-language write-up so the result is not just my word for it.
Let's talk
Tell me what your MySQL is doing to you: the page that times out, the CPU alarm, the report nobody can run at month-end. A thirty-minute discovery call is free, no deck, no sales, just a straight answer on whether I can help and what it would take.