Introduction

Importing a data.sql file into MySQL inside Docker is usually simpler than it first looks. The key is to decide whether you want the file loaded automatically when the container is created or manually imported into an already running container.

Option 1: Import automatically on first container startup

The official MySQL image looks for initialization scripts in /docker-entrypoint-initdb.d. Any .sql file in that directory is executed the first time the container creates its database files.

This is the cleanest option when you are bootstrapping a fresh local environment.

1docker run --name mysql-demo \
2  -e MYSQL_ROOT_PASSWORD=secret \
3  -e MYSQL_DATABASE=appdb \
4  -v "$PWD/data.sql:/docker-entrypoint-initdb.d/data.sql" \
5  -p 3306:3306 \
6  -d mysql:8

Important detail: this import happens only when the data directory is empty. If the container already has existing database files, the entrypoint skips initialization scripts.

That means if you change data.sql and restart the same container, nothing new is imported. For a fresh load, remove the container and its volume, or create a new one.

Option 2: Import into a running container

If the container is already running, pipe the SQL file into the mysql client using docker exec.

docker exec -i mysql-demo \
  mysql -uroot -psecret appdb < data.sql

This is often the best choice for restoring a dump, loading fixtures, or re-importing data into an existing environment.

You can verify the import by running a quick query:

docker exec -it mysql-demo \
  mysql -uroot -psecret -e "SHOW TABLES IN appdb;"

The -i flag matters because it keeps standard input open so the file can be streamed into the client process inside the container.

Option 3: Copy the file into the container first

If you prefer to inspect the file inside the container, copy it and then execute the import from a shell command.

1docker cp data.sql mysql-demo:/tmp/data.sql
2
3docker exec -it mysql-demo \
4  sh -c 'mysql -uroot -psecret appdb < /tmp/data.sql'

This is useful when the file is generated elsewhere or when you want to debug file permissions and encoding inside the container itself.

Creating the database before import

If your SQL file does not contain a CREATE DATABASE statement, the target database must already exist.

docker exec -it mysql-demo \
  mysql -uroot -psecret -e "CREATE DATABASE IF NOT EXISTS appdb;"

Then import the file into that database.

Some dump files already include statements such as USE appdb; or CREATE DATABASE. If so, you may not need to name the database explicitly on the command line. It depends on how the dump was created.

Inspecting logs and import failures

If the import fails, the error usually falls into one of these categories:

• wrong password or user
• target database does not exist
• SQL file contains syntax incompatible with the MySQL version
• character set mismatch
• the container was expected to auto-import, but the data directory was not empty

Container logs can help when startup initialization fails:

docker logs mysql-demo

For manual imports, the error often appears directly in the terminal because the mysql client prints the failing statement and line number.

When to use mounted initialization files

Initialization scripts are ideal for repeatable development environments, especially with Docker Compose. If the goal is "start the container and get a ready-to-use schema", mounting data.sql into /docker-entrypoint-initdb.d is the right pattern.

For ad hoc restores or daily import work, docker exec -i ... < data.sql is more flexible because it does not require recreating the container.

Common Pitfalls

• Expecting /docker-entrypoint-initdb.d scripts to run again on every container restart.
• Forgetting -i when piping the SQL file into docker exec.
• Importing into a database that does not exist yet.
• Using the wrong credentials or assuming the root password from an old container still applies.
• Blaming Docker when the real issue is SQL syntax or a version mismatch in the dump file.

Summary

• Use /docker-entrypoint-initdb.d for one-time initialization of a fresh MySQL container.
• Use docker exec -i ... mysql ... < data.sql to import into a running container.
• Create the database first if the SQL file does not do it for you.
• Check container logs for startup imports and terminal output for manual import failures.
• The most common source of confusion is that initialization scripts only run on first database creation.