Database
MySQL
A lot of the web runs on MySQL, often without anyone having chosen it on purpose. We review, tune, upgrade, and move MySQL databases, and we say plainly when staying put is the sensible answer.
- 1,200+ clients helped
- Building since 2010
- 15 services, one team
- 50+ technologies
At a glance
What it is
MySQL is one of the most widely used databases. It stores the data behind WordPress, most online stores built on it, and a large number of PHP applications.
Problems it solves
A MySQL database that has run for years can become slow, sit on an old version that no longer gets fixes, or be tied to a server nobody wants to touch.
Who it suits
Owners of WordPress or PHP systems, and teams responsible for a MySQL database they did not design.
How to choose
Keep MySQL when it serves the application well and is kept up to date. Move only for a clear reason, such as features you need or an application being rebuilt.
Why it matters
The database nobody chose
MySQL is rarely picked after a long comparison. It arrives with a platform. WordPress uses it, and so does the store built on top of it. A great many PHP applications were written for it from the start.
That history shapes the decisions. The database is often older than anyone on the team, and it carries years of data. Changing it feels risky, so it is left until something forces the issue: a slow page, a security notice, a host that ends support.
Our job is to look before that happens. Most MySQL problems come from a small set of causes, and most can be fixed without replacing anything.
Situations
Common MySQL situations and what we do
Usual cause
Missing indexes, a bloated options table, or too many add-ons querying on every page.
- Usual remedy
- Targeted indexes, clean-up of stored data, and fewer or lighter add-ons.
Usual cause
An old release that the host or the vendor is retiring.
- Usual remedy
- A tested upgrade to a supported release, with the application checked first.
Usual cause
Heavy reporting queries run against the system that takes orders.
- Usual remedy
- A read copy for reports, or data moved to a warehouse.
Usual cause
A rebuild, a need for richer data types, or a standard on another database.
- Usual remedy
- A planned move, usually to PostgreSQL, done in stages and checked row by row.
How we review it
Four checks on a MySQL database
Version and support
We confirm the release in use and whether it still receives security fixes. Old releases are the most common hidden risk.
What it produces
- Version report
Speed
We find the slowest queries and the pages that wait on them. Missing indexes and oversized queries cause most delay.
What it produces
- Slow query list
Safety
We test that backups can actually be restored, and that access to the database is limited to what needs it.
What it produces
- Restore test
- Access review
Where it runs
A single unmanaged server is a single point of failure. We compare it with a managed service.
What it produces
- Hosting options
What DECHY can do
Working with MySQL
Review
- A short health check of version, speed, backups, and access.
- A written list of what to fix first.
Tune and upgrade
- Index and query work that makes pages load faster.
- Version upgrades tested on a copy before they touch live data.
Host well
- Moving to a managed MySQL service on AWS, Azure, or Google Cloud.
- Backups, failover, and monitoring that you can see.
Move
- Migration to PostgreSQL when there is a clear reason.
- Data checks that prove nothing was lost or changed.
Common questions
Questions about MySQL
Is MySQL outdated?
No. It is actively maintained and widely used. The risk is an old release or an unmanaged server, not the product.
Do we have to move to PostgreSQL?
No. Move only if you have a reason, such as features you need or a rebuild under way. For many WordPress and PHP systems, a well-kept MySQL is the right choice.
Will a version upgrade break our site?
It can if untested. We upgrade a copy first, run the application against it, and only then touch live data.
Why is our WordPress site slow when the server is large?
Often the database is the bottleneck: missing indexes, large stored settings, or add-ons that query heavily. A review finds the cause.
Have a different question?
Tell us what you are weighing up and we will answer it plainly.
Ask a questionAlready a client? Email support@dechytech.com
Technical depth
How we build with MySQL
What we settle early on MySQL work: engine and schema, performance, availability, MariaDB, and migrating away, so nothing surprises your team later.
- We confirm tables use the InnoDB engine, which supports transactions and recovery after a crash.
- We check character sets and collations, because mixed settings cause subtle comparison and sorting faults.
- We look for unused and duplicate indexes, which slow writes without helping reads.
- The slow query log and the query plan show where time goes.
- Buffer and connection settings are sized to the server's memory and the real number of connections.
- Long-running transactions and lock waits are traced to the code that causes them.
Managed services provide automated backups, point-in-time recovery, and a standby copy in another zone. A read replica lets reports run without slowing the live database.
MariaDB began as a fork of MySQL and the two have drifted apart. Some hosts offer one or the other. We check compatibility before moving between them, because they are not drop-in replacements for each other in every case.
A move to PostgreSQL maps data types, rewrites queries that use MySQL-only behavior, runs both databases in parallel, and compares results before the switch.
Tell us about your MySQL database
Tell us which application uses it and what feels wrong. We will review it and recommend whether to tune, upgrade, rehost, or move.