Extract a single table from a MySQL dump

Not every job needs the whole database. When you're building a feature locally, you rarely want a full production dump filling your disk and taking an hour to import. You want the handful of tables the feature actually touches.

The same is true when you're debugging a single table — reproducing a data issue in orders doesn't require the other 126 tables — or doing a partial migration, where only a few tables move to a new service. In all of these cases the question is the same: how do I get just these tables out of a giant dump, cleanly and quickly?

The sed/grep approach and why it breaks

The classic answer is to slice the file with sed between the section headers mysqldump writes for each table:

# pull the users table out of a mysqldump file
sed -n '/-- Table structure for table `users`/,/-- Table structure for table/p' dump.sql > users.sql

It looks clever, and on a small, tidy dump it might even work once. On a real 7 GB file it falls apart in a lot of subtle ways:

• Multi-line INSERTs. A single INSERT INTO ... VALUES can span thousands of lines. Line-oriented tools like sed and grep cut those rows in half and produce a file that won't parse.
• Backticks and special characters. Column values contain --, semicolons, backticks, quotes and newlines inside strings. Your pattern matches text inside data that was never meant to be a delimiter.
• Table names as substrings. Extracting user also grabs user_roles, user_sessions and password_user, because the name appears as a substring of others.
• Comments and headers drift. The exact comment text varies between MySQL, MariaDB and PostgreSQL versions, and pg_dump doesn't use the same headers at all — so the same command silently returns nothing.
• No foreign key awareness. Even if you slice orders perfectly, its rows reference users. sed has no idea, so the extract fails to import with a foreign key error.

You end up piling awk onto grep onto sed, testing on subsets, and still not trusting the result. There's a better way.

Extract tables with DumpCleaner

DumpCleaner parses the dump properly — it understands statement boundaries, multi-line INSERTs, backticks and comments — so it always cuts on the right lines. Extracting the tables you need takes four steps:

1. Drag your .sql dump in. DumpCleaner streams the file, so a 7 GB dump opens with constant memory instead of loading the whole thing.
2. Read the auto-detected table list. Every table is parsed out and listed with its row count and size — no scrolling through millions of lines to find what's there.
3. Pick the tables you want. Tick users, orders and products, or type a regex / exclude pattern such as *_logs to drop whole groups in one go.
4. Include foreign key parents and export. Optionally pull in referenced parent tables automatically, then export a clean, importable file.

A few things make this a lot less fiddly than shell tools:

• Exclude patterns like *_logs or *_sessions strip out audit and session noise without unticking dozens of tables by hand.
• Regex filters let you match by prefix, suffix or any pattern — keep everything matching shop_*, for example.
• A live preview shows exactly which tables will end up in the output as you change the selection.
• An estimated output size tells you how big the extract will be before you export, so you know it'll fit locally.
• Foreign key dependencies can be included automatically, so picking orders quietly brings users along and the extract imports without constraint errors.

Frequently asked questions