Finding and exporting your MySQL data

What it holds

MySQL keeps structured application records and the relationships between them. Orders, customers and status events remain available only as long as the application retains their rows.

Where MySQL shows the size

1. Run SELECT table_schema, ROUND(SUM(data_length + index_length) / POW(1024,3), 2) AS size_gb, SUM(table_rows) AS approx_rows FROM information_schema.TABLES WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys') GROUP BY table_schema ORDER BY size_gb DESC;
2. To bypass cached statistics, first run SET SESSION information_schema_stats_expiry = 0; or refresh relevant tables with ANALYZE TABLE.
3. Use SELECT COUNT(*) on important tables if estimated TABLE_ROWS values are insufficient.

Plan and admin role. Available across MySQL editions. Use an account with visibility and SELECT access across the application schemas; export routines, events and other objects may require additional privileges.

Exporting the full history

1. Use a replica where practical. Export an InnoDB schema with mysqldump --single-transaction --routines --triggers --events --databases app_db > app_db.sql.
2. For parallel, compressed output, use MySQL Shell: util.dumpInstance('/backup/full-dump') or util.dumpSchemas(['app_db'], '/backup/app-dump').

Metadata statistics normally remain cached for 24 hours; InnoDB row estimates can differ substantially from actual counts.

--single-transaction supplies snapshot consistency for InnoDB, not every storage engine. Without it, mysqldump requires LOCK TABLES; avoid assuming a mixed-engine export is consistent.

MySQL Shell defaults to four threads and zstd-compressed tab-separated chunks. Large SQL dumps can be slow both to produce and to restore.

You don't need to run an export to talk to us, and there's no need to clean it first — removing personal data is part of our work.