MySQL Administrator Interview Questions for AI Training Work

I check the query execution plan first to see if it's still using the expected indexes, since a plan change, often caused by stale statistics or data growth, is a common cause of sudden slowdowns. I also check for locking contention from other queries before assuming the query itself is the problem.

I combine periodic full backups with more frequent incremental or binary log based backups, scheduling the heavier full backups during lower-traffic windows, rather than running full backups constantly regardless of load. This keeps recovery point objectives tight without degrading performance during peak hours.

I weigh the read performance benefit against the write overhead an additional index adds, since a table with heavy write traffic can suffer noticeably from an index that mostly helps a rarely run query. I check query frequency and existing index coverage before adding anything new.

I enforce least-privilege access at the user and schema level rather than relying on broad admin accounts for routine application access, and I make sure network access is restricted to only what genuinely needs it. I also keep the instance patched and audit for unused accounts or overly permissive grants periodically.

I run periodic test restores to a separate environment rather than assuming a backup that completed successfully is automatically usable, since a backup process can appear to succeed while producing a file that fails to restore cleanly. Finding that out during a drill is far better than finding out during an actual outage.

I'd first check for the most common quick fixes, like a runaway query holding locks or a resource exhaustion issue, before assuming a full restore is necessary, since a targeted fix restores service faster than a full recovery when the cause is something transient. I'd only move to restoring from backup if the issue points to actual data corruption or unrecoverable failure.

I'd scope the permissions down to what the application actually uses, testing carefully in a staging environment first, rather than leaving it as is because it's been working. I'd also review other accounts for similar overprovisioning rather than treating this as an isolated case.

I'd start by inventorying accounts and their actual permissions against what's genuinely needed, since accumulated over-permissioning is common in long-running systems, and I'd prioritize closing the highest-risk gaps, like broad remote access or unused privileged accounts, before doing a more exhaustive review.

A dashboard query that ran frequently was scanning far more rows than necessary due to a missing composite index. Adding the right index cut its execution time dramatically, and because that query ran so often, the overall database load dropped noticeably, which freed up headroom for other queries that had also been struggling.

A table was accidentally truncated by a faulty deployment script. Because I had point-in-time recovery set up using binary logs alongside regular full backups, I was able to restore the database to just before the incident with minimal data loss, which validated that the backup strategy worked exactly as designed under real pressure.