export schema dumps the database structure (tables, indexes, routines, triggers, views) to a .sql file without data.
Exporting just the schema lets you version-control structural changes, replicate environments quickly, and perform zero-data migrations in CI/CD pipelines.
Use mysqldump
(or the identical mariadb-dump
) with --no-data
. This flag skips row data while preserving CREATE statements for tables, triggers, views, and routines.
Run:mysqldump -u admin -p --host=db.prod --no-data --routines --triggers --databases shop > shop_schema.sql
This writes CREATE TABLE
, CREATE VIEW
, CREATE TRIGGER
, and CREATE PROCEDURE
statements for database shop
.
Supply the table name:mysqldump -u admin -p --no-data shop Customers > customers_schema.sql
Useful for modular migrations or when just one table changes.
Pipe the dump file into the target server:mysql -u admin -p --host=db.staging < shop_schema.sql
Ensure the destination user has CREATE
privileges.
Add a job that runs mysqldump
nightly, commits the *.sql
file to VCS, and tags releases. Compress large dumps with gzip
to save storage.
• Always append --set-gtid-purged=OFF
in GTID setups.
• Use --skip-add-drop-table
when you want idempotent CREATE statements.
• Store dumps in a dedicated /db/schema/
directory.
Omitting --no-data
writes millions of rows into the file. Always include it when the goal is structure only.
--no-create-info
removes CREATE statements and leaves INSERTs—exactly the opposite of what you want. Swap it for --no-data
.
Open the file and search for INSERT INTO
. If none exist, you successfully exported schema only.
Yes. Views, triggers, routines, and events are included when you add their respective flags (--routines
, --triggers
, --events
).
Yes. List them after --databases
or use --all-databases
. Each schema will be wrapped in a corresponding CREATE DATABASE
statement.
With --single-transaction
, InnoDB tables are dumped from a consistent snapshot without locking writes, making it safe for production usage.