On this page
MySQL often feels import slow after a big dump because InnoDB is still flushing writes, rebuilding indexes, and catching up on statistics. If the disk was already near full, the engine also struggles to write undo and temporary data, so every query after the load stays sluggish. Treat the import as a heavy write storm, free space first, then finish with ANALYZE TABLE and a short wait.
Check disk space before you start
Do not begin a large restore when the partition is already around 95 percent full. InnoDB needs room for undo, temporary tables, and normal flush activity during the load. If free space is tight, delete old backups, rotate logs, or move files off the volume first. Watching disk usage while the import runs helps you stop early instead of freezing the server mid-load.
Run the import in a safer way
phpMyAdmin will usually time out on a multi-gigabyte dump, so use SSH and a pipe or the mysql client for large files. Turning off foreign key checks for the load can speed a huge schema, but turn them back on and verify when you finish. Prefer a spare database or a maintenance window over importing straight into live production tables during busy hours. A half-finished schema with open customer writes is much harder to recover from than a planned cutover.
Finish with stats, patience, and a quick check
After the data is in, run ANALYZE TABLE on the large tables so the optimizer is not working from empty or stale stats. InnoDB may need several minutes for purge, history list cleanup, and buffer pool warm-up; that calm-down period is normal. Open a few admin screens and watch early cron writes before you call the restore done. If binary logs are enabled, they grow with every imported row and can fill the disk a second time; see binary logs filling the disk if the partition filled during or after the load.
Tagged
Was this article helpful?
Be the first to rate this article.
