Introduction

The MySQL error Tablespace for table xxx exists. Please DISCARD the tablespace before IMPORT appears during an InnoDB tablespace import when MySQL believes the target table already has an attached .ibd tablespace. This usually happens in file-per-table workflows where a table definition exists in MySQL and you are trying to attach or reattach a physical tablespace file.

The message is very specific: MySQL will not import the incoming tablespace until the current one is discarded. That protects the server from attaching the wrong file to an existing table definition.

When This Error Happens

This problem typically appears in workflows like these:

• restoring an InnoDB table from a copied .ibd file
• moving a table between servers with DISCARD TABLESPACE and IMPORT TABLESPACE
• retrying an import after a partial failure
• importing into a table whose old .ibd file still exists on disk

It is much less common in normal logical backups created with mysqldump, because logical dumps recreate data through SQL rather than attaching a physical tablespace file.

How InnoDB Tablespace Import Works

A physical import normally follows this pattern:

1. Recreate the table definition on the target server.
2. Discard the target table's current tablespace.
3. Copy the source .ibd file into the target database directory.
4. Import that tablespace into the table.

The SQL commands look like this:

1CREATE TABLE orders (
2    id BIGINT PRIMARY KEY,
3    customer_name VARCHAR(100),
4    total DECIMAL(10, 2)
5) ENGINE=InnoDB;
6
7ALTER TABLE orders DISCARD TABLESPACE;
8
9-- Copy orders.ibd into the database directory at the filesystem level
10
11ALTER TABLE orders IMPORT TABLESPACE;

If you skip the discard step or if MySQL still thinks a tablespace is attached, the import is blocked with this error.

The Safe Recovery Flow

Before touching the table, confirm that the table definition on the target matches the original source exactly. The column order, data types, indexes, row format, and engine settings must be compatible. A mismatched definition can cause import failure even after discarding properly.

A typical repair sequence is:

ALTER TABLE orders DISCARD TABLESPACE;

Then copy the correct .ibd file into place and run:

ALTER TABLE orders IMPORT TABLESPACE;

If the table was created from a .sql schema export and the old .ibd file is still present in the database directory, make sure you are not accidentally mixing stale files with the new import attempt.

Filesystem and Metadata Must Agree

This error often means MySQL metadata and filesystem state disagree. For example:

• the table exists in the data dictionary
• an .ibd file already exists for that table
• the server believes the table still owns a live tablespace

Discarding tells MySQL to detach the current tablespace from the table metadata. Only then can a new physical file be imported safely.

Because of that, deleting .ibd files by hand without updating MySQL metadata is risky. Use the SQL workflow first, then perform the file copy step deliberately.

When mysqldump Is the Better Choice

If your goal is just to move data between servers and you do not specifically need physical tablespace import, a logical export is simpler and safer:

mysqldump -u root -p mydb orders > orders.sql
mysql -u root -p mydb < orders.sql

That approach avoids direct .ibd management entirely. Physical tablespace import is mainly useful for specific recovery, transportable tablespace workflows, or very large data movement scenarios.

Common Pitfalls

The biggest pitfall is running IMPORT TABLESPACE against a table whose current tablespace was never discarded. That is exactly what this error is warning about.

Another issue is using a source .ibd file with a table definition that does not match the target schema. Even if the discard step succeeds, the import can still fail later with metadata mismatch errors.

Manual file deletion is another common mistake. Removing the .ibd file at the filesystem level without the corresponding SQL steps can leave InnoDB metadata in an inconsistent state.

Finally, do not use this workflow casually on production data without backups. Tablespace operations are lower-level than normal SQL import/export and are much less forgiving of mistakes.

Summary

• This error appears when MySQL thinks the target InnoDB table already has an attached tablespace.
• The standard fix is ALTER TABLE ... DISCARD TABLESPACE before IMPORT TABLESPACE.
• The target table definition must match the source tablespace exactly.
• Physical .ibd import is different from logical tools such as mysqldump.
• Treat tablespace operations carefully and take backups before making changes.