COPY TABLE BETWEEN DATABASES copies a table’s structure and/or data from one MySQL schema to another.
Migrating data, splitting monolith schemas, or preparing test environments often requires moving an entire table—including indexes—into another database quickly.
The two fastest native approaches are: 1) CREATE TABLE newdb.tbl LIKE olddb.tbl then INSERT…SELECT; 2) mysqldump of a single table piped into mysql.Most teams use method 1 for in-server moves and method 2 for cross-server transfers.
Run two statements: CREATE TABLE target_db.table LIKE source_db.table; INSERT INTO target_db.table SELECT * FROM source_db.table; Both execute on the same MySQL instance.
Skip the INSERT.The CREATE TABLE LIKE command duplicates columns, indexes, AUTO_INCREMENT, and default values but omits rows.
If the destination table already exists with the desired schema, run INSERT INTO dest_db.table SELECT * FROM src_db.table; Rows append without touching structure.
Use mysqldump: mysqldump -hsrc -uuser -p src_db table | mysql -hdst -uuser -p dst_db. This streams the CREATE TABLE and INSERT statements over the network.
Yes.Add a WHERE clause to INSERT…SELECT. Example: INSERT INTO dst_db.Orders SELECT * FROM src_db.Orders WHERE order_date < '2024-01-01';.
Copy parent tables before child tables. Disable foreign_key_checks=0 during the process, then set it back to 1 after all INSERTs finish.
Copy during off-peak hours, add LIMIT…OFFSET batches, and monitor replica lag. For mysqldump, use --single-transaction to avoid locking innodb tables.
Inside one server, use CREATE TABLE LIKE + INSERT…SELECT. Across servers, stream with mysqldump.Always verify row counts and re-enable constraints.
.
No. It copies columns and indexes only. Dump triggers separately with mysqldump --triggers.
Yes. List columns explicitly in INSERT…SELECT, e.g., INSERT INTO dst_db.Customers (id,name) SELECT id,name FROM src_db.Customers;
Replication syncs continuous changes, while COPY TABLE is a one-off move. Choose replication for ongoing data flows.