Performance Glossary
MySQL: Finding the Queries That Own Your TTFB
The page cache handles your traffic beautifully until someone logs in, searches, or reaches checkout, and then the database is the whole response time.
The short answer
MySQL is the relational engine holding the content, users and orders behind most hosted applications, and it is where the time goes on every request the page cache cannot answer.
Finding the cost is mechanical: enable the slow query log or read the query list your profiler produces, sort by total time rather than by count, and start at the top. The worst offender is usually one query running far more often than anyone expected.
By the HostingFast team · Reviewed 12 August 2026
0
Terms, measured not asserted
100+
Entries wired together
Real
Queries you can run
Free
Free to read, always
Applications speak SQL to it, hosting panels create the databases and their users, phpMyAdmin gives you a window on the contents, and MariaDB is the drop-in fork you will meet just as often. None of that changes how you profile it.
On WordPress specifically, two things dominate: the autoloaded options row, which is read on literally every request, and post meta tables that grow without limit because nothing ever deletes from them. Both are measurable in one query each.
Where the time is, in one query
Start with the autoload total: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'. Anything into the megabytes is being read on every single request, cached page or not, and trimming it is the cheapest win available on a neglected WordPress install.
Then find the tables themselves. Querying information_schema for data_length plus index_length, ordered descending, ranks your tables by size in seconds. A post meta table dwarfing the posts table is the classic signature of a plugin writing rows it never removes.
What an index actually changes
EXPLAIN in front of a slow query tells you whether the engine is scanning the whole table or seeking through an index. The rows column is the number that matters: a query examining half a million rows to return twelve is doing work the index would have avoided entirely.
Indexes are not free. Each one costs storage and slows writes, so add them for the queries your profile actually named rather than sprinkling them across likely-looking columns. Measure the query time before and after; if it did not move, remove the index again.
Storage latency underneath the query
A query the buffer pool cannot satisfy goes to disk, which is where NVMe earns its place: the difference between spinning storage and flash is measured in whole milliseconds per read, repeated for every read a scan performs. That is the same reason a bloated table hurts twice.
It is also why a database that fits in memory behaves so differently from one that does not. Trimming revisions, transients and orphaned meta is not housekeeping — it is the change that moves your working set back inside the buffer pool.
Proving the trim worked
Take the uncached response time for a logged-in page before you start, then again after the cleanup, three runs each and compare medians. Pair it with the table sizes from the same information_schema query so you have both cause and effect in one place.
Back up before every one of those steps. Panel backups include databases, a phpMyAdmin export gives you a portable .sql file, and WP-CLI on a schedule automates the whole thing. The only unforgivable state is having no copy, or having one nobody has ever restored.
Database advice with the query attached
No entry here tells you to optimise your database. Each one names the query that shows you where the time is and the reading that proves it moved.
Databases sit on NVMe across every tier, and daily backups restore from your own panel without a ticket queue in the way.
- The diagnostic query, written out
- EXPLAIN read column by column
- Storage latency accounted for
- Backup before every change
Why HostingFast
Standard on every plan
Diagnosis before prescription
Every recommendation starts from a query you run against your own data rather than a general rule.
EXPLAIN made usable
Which column of the output settles whether an index is missing, and what the rows figure is telling you.
Bloat quantified
How to measure autoloaded options and table growth, so a cleanup has a before figure to beat.
Indexes treated as a trade
What one costs on writes and storage, and the test that says whether it earned its place.
Storage in the picture
Why the same query behaves differently once the working set no longer fits in memory.
Restore rehearsed, not assumed
The three ways to take a copy here, and the reason an untested backup is not one.
Quick Start
From order to online
- 1
Measure the autoload total first
One SELECT over wp_options tells you how much data is read on every request. It is the fastest finding available and often the biggest.
- 2
Rank your tables by size
Query information_schema for data and index length, ordered descending. The top three explain most of what a backup and a scan are doing.
- 3
EXPLAIN the slowest query
Read the rows examined against the rows returned. That ratio, not the query text, tells you whether an index is the answer.
Built In
Loaded onto every plan
- NVMe on every tier — the entry plan runs the same drives as the top one
- Daily backups with a self-service restore you run yourself from the panel
- PHP version selectable per site, switched from the control panel in seconds
- SSH, Git and Composer on the developer-focused plans
- LiteSpeed compiled into the server, not a caching plugin bolted on afterwards
- Staging you can clone, break and throw away before anything reaches live
- cPanel, so every script and tutorial you already have still applies
- 99.9% uptime as the target, monitored around the clock
- Mailboxes on your own domain, with IMAP, POP, SMTP and webmail
- Renewal billed at your signup rate — no year-two step change
Frequently Asked
What people ask us most often
Does the MySQL or MariaDB question ever reach a site owner?
Almost never for hosted applications. MariaDB is a compatible fork and your application will not notice which it is talking to. What decides your response time is the storage underneath, the indexes on your tables and how much of the working set fits in the buffer pool.
Which is the right way to take a database copy here?
Panel backups include databases, a phpMyAdmin export produces a portable .sql file you can inspect, and WP-CLI on a cron schedule automates dumps. Pick on convenience — all three restore. The genuine failure is owning no copy, or owning one nobody has ever restored from.
Can I run a restore without opening a ticket?
Yes. Every plan takes a daily backup and the restore runs from your own panel — files, databases or both — at whatever hour you discover the problem. Keeping an additional copy somewhere off our network remains good practice, and nothing in the platform stops you doing it.
Do I get shell access on shared hosting?
On the developer-focused plans, yes — SSH, Git and Composer included. Every account runs isolated, so a shell session reaches your files, your databases and your processes and nothing beyond them. That is what makes WP-CLI and push-to-deploy workflows practical without renting a VPS.
Keep reading
NVMe
Flash over PCIe, and the storage latency difference you can actually measure.
Database
The queryable half of a site, and why a restore is never files alone.
How to Optimize a MySQL Database
Finding the slow queries, trimming the bloat and measuring what the trim returned.
Web Hosting
cPanel hosting on NVMe with LiteSpeed, free SSL and a migration included.
PHP Hosting
Per-site PHP version switching on NVMe hardware, with OPcache already warm.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Put the buffer pool on faster storage.
NVMe on every tier, daily database backups you restore yourself, and SSH with WP-CLI on the developer plans.
View Web Hosting plans