Using the MySQL SOURCE Command to Import a SQL File
SOURCE vs the < redirect — when to use each, why SOURCE sometimes fails on big files, and how to see errors instead of silent stops.
SOURCE runs a SQL file from inside the MySQL prompt. It's handy when you're already connected, but it behaves differently from the shell redirect — and that difference bites people on large imports.
The basic SOURCE syntax
-- from inside the mysql> prompt
USE your_database;
SOURCE /full/path/to/dump.sql;SOURCE doesn't understand ~ for your home directory and doesn't want quotes around the path. /Users/you/dump.sql works; "~/dump.sql" does not.
SOURCE vs the < redirect
For very large dumps, the shell redirect is usually the safer choice — it streams the file rather than loading it through the interactive client:
mysql -u user -p your_database < /path/to/dump.sqlWhy SOURCE 'finishes' but nothing imported
If SOURCE returns to the prompt instantly with no error and no data, the path is wrong — MySQL couldn't open the file. Double-check the absolute path and that the file is readable by the user running mysql.
See errors instead of silent stops
By default a single bad statement aborts the import. To push through recoverable errors (useful for messy dumps), start mysql with --force:
mysql -u user -p --force your_database < dump.sql 2> import_errors.logRedirecting STDERR to a log file gives you a list of exactly which statements failed, instead of guessing.
Big dump dying mid-SOURCE?
Split it into smaller files and SOURCE them in order — each one is independently importable.
Open SQLSplitFrequently Asked Questions
What's the difference between SOURCE and mysql < file.sql?
SOURCE runs from inside the mysql prompt; the < redirect runs from your shell. For very large files the shell redirect streams more efficiently, while SOURCE is convenient when you're already connected interactively.
Why does MySQL SOURCE say 'No such file or directory'?
SOURCE needs an absolute path with no quotes and no ~ shortcut. Use the full path like /Users/you/dump.sql and make sure the file is readable by the OS user running the mysql client.
How do I make MySQL continue importing after an error?
Start the client with --force so it skips failed statements instead of aborting. Redirect STDERR to a log file (2> errors.log) to capture exactly which statements failed.