"Your file could not be loaded as a MySQL dump"
This message means the uploaded file is not a plain SQL script produced by
mysqldump. SwapSQL reads the CREATE TABLE and INSERT
statements out of a real dump; if it cannot find them, it stops before doing any conversion.
Below are the eight reasons a file gets rejected, in roughly the order they happen, and how to
fix each one.
1. It is not SQL at all
The most common cause: the file is a spreadsheet (.csv, .xlsx), a
JSON export, or a raw InnoDB data file (.ibd, .frm,
.myd). None of these are a dump. A dump is a text file full of SQL statements.
Check what you actually have:
file mydata # should say: ASCII text / UTF-8 Unicode text
head -n 15 mydata # should show "-- MySQL dump" and CREATE TABLE lines
If head shows columns of comma-separated values or unreadable binary, you exported
data, not a schema-and-data dump. Re-export with mysqldump (below).
2. It is a ZIP or other archive
SwapSQL accepts a plain .sql file or a single gzip-compressed
.sql.gz. It does not unpack .zip, .7z,
.tar or .tar.gz archives — those can hold many files, so there is no
single dump to read. Extract the SQL first, then gzip it on its own:
unzip backup.zip # gives you dump.sql
gzip dump.sql # produces dump.sql.gz — upload this3. It is actually a PostgreSQL dump
A file from pg_dump is full of PostgreSQL syntax (COPY ... FROM stdin,
SERIAL, SET search_path) and will never load as a MySQL dump. You are
simply on the wrong tool — convert it the other way with
PostgreSQL to MySQL instead.
4. It is a multi-file MySQL Shell export
util.dumpInstance() / util.dumpSchemas() in MySQL Shell, and
mysqldump --tab, do not produce one SQL file — they write a folder of
.tsv/.sql pieces. Upload one of those pieces and it is incomplete.
Re-export as a single classic dump:
mysqldump --single-transaction --no-tablespaces \
-u root -p mydatabase > dump.sql5. The download was truncated
A dump that was interrupted mid-transfer, or copy-pasted out of a GUI text box, often ends in
the middle of a statement. A valid mysqldump file ends with a comment line such as
-- Dump completed on …. Confirm yours does:
tail -n 5 dump.sql # look for "Dump completed"If that line is missing, re-export and download the whole file.
6. It is UTF-16 or has a byte-order mark
Some Windows tools save SQL as UTF-16, which the parser cannot read as expected. Convert it to plain UTF-8 (this also strips a leading BOM):
iconv -f UTF-16 -t UTF-8 dump.sql -o dump.utf8.sql7. It is a physical/binary backup
Percona XtraBackup output, a copied /var/lib/mysql data directory, or an
.xbstream file are physical backups, not logical dumps. There is no SQL text to
parse. Restore the backup to a running MySQL server first, then take a logical dump from it
with mysqldump.
8. The file is empty
A zero-byte file usually means the mysqldump command failed (wrong password, no
SELECT grant) but the empty redirect file was still created. Check the size and
re-run the export, watching for errors:
ls -lh dump.sql # 0 bytes means the export never ranThe command that always produces a loadable file
When in doubt, regenerate the dump from a running MySQL server. This is the exact format SwapSQL expects:
mysqldump --single-transaction --no-tablespaces \
-h localhost -u root -p mydatabase > dump.sqlOn shared hosting without SSH, phpMyAdmin works too: pick the database, choose Export → Quick → SQL, and upload the resulting file. For the full set of export flags and Docker/remote variants, see how to export a MySQL dump.
Got a clean .sql (or .sql.gz)?
Convert it to PostgreSQL now →