Introduction

Importing a .sql file into MySQL is usually a matter of feeding SQL statements into the MySQL client, but the details matter. You need the right target database, the right credentials, and a file that matches the server version and character set you are importing into.

The standard command-line import

The most direct approach is to stream the file into the mysql client:

mysql -u root -p appdb < backup.sql

This command does three things:

• starts the MySQL client
• connects as root
• sends the contents of backup.sql into the selected database

If you omit the database name, the file itself must contain USE database_name; or explicit fully qualified table names.

For many teams, this is the preferred method because it works well with large dump files and fits into repeatable operational workflows.

Creating the database first

If the target database does not exist, create it before importing unless the SQL file already does that for you.

mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS appdb;"
mysql -u root -p appdb < backup.sql

Many export tools generate files that contain only table definitions and inserts. In that case, the database must already exist or the import will fail.

Importing from inside the MySQL shell

You can also start an interactive MySQL session and use the source command:

mysql -u root -p
USE appdb;
SOURCE /full/path/to/backup.sql;

This is convenient when you are already connected and want to test several commands before or after the import.

Character set and version concerns

Imports that look correct can still fail if the dump was created on a different MySQL or MariaDB version, or if the file encoding does not match the target database.

If the dump is UTF-8 and the client defaults do not match, specify the character set explicitly:

mysql --default-character-set=utf8mb4 -u root -p appdb < backup.sql

This is especially important when importing text with accented characters, emoji, or multilingual content.

Large file imports

For big dump files, the command-line client is usually better than browser-based tools such as phpMyAdmin. Web interfaces can hit upload limits, request timeouts, or memory limits long before MySQL itself becomes the bottleneck.

If you are dealing with a very large import, these settings are often relevant:

• 'max_allowed_packet'
• 'innodb_log_file_size'
• client and server timeouts

A common operational pattern is to compress the dump for storage and then decompress it directly into MySQL:

gunzip < backup.sql.gz | mysql -u root -p appdb

That avoids creating another large temporary file on disk.

Verifying the import

After the import, do not assume success just because the command ended. Check that the expected tables and row counts exist.

mysql -u root -p -e "SHOW TABLES IN appdb;"
mysql -u root -p -e "SELECT COUNT(*) FROM appdb.users;"

Verification is important for schema-only dumps, partial imports, and large restores where a failure can happen halfway through.

When GUI tools are acceptable

MySQL Workbench and phpMyAdmin can be useful for smaller imports, especially for local development. They are easier for one-off tasks when you do not want to remember client flags. Still, the command line is more predictable, more automatable, and usually better for large files.

If you are troubleshooting an import problem, the command line also gives clearer error messages.

Common Pitfalls

• Importing into the wrong database because the file does not include a USE statement.
• Forgetting to create the target database before import.
• Hitting encoding problems because the client and dump file character set do not match.
• Using browser-based tools for very large files and running into timeouts.
• Assuming the import succeeded without checking row counts or table presence afterward.

Summary

• The standard import pattern is mysql -u user -p database < file.sql.
• Create the database first unless the dump file already does it.
• Use SOURCE inside the MySQL shell when interactive import is more convenient.
• Prefer the command line for large files and clearer diagnostics.
• Check character set settings and verify the imported data after the command finishes.