Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

You could restore the dump into a new database, drop all the tables you don't need from the new database, then dump the new database and restore the new dump against the original database.
–
Max VernonSep 27 '12 at 5:05

1 Answer
1

Unless some unusual options are used when it is invoked, the files produced by mysqldump contain the raw sql statements needed to drop and recreate your tables as they existed at the time the dump was done, uncompressed, and human-readable. They can generally be manipulated with a text editor... although finding a text editor that works well with 20GB files is another matter.

But restoring an individual table essentially requires extracting the lines you want, and piping those statements into the server via the mysql CLI. Of course, I would not recommend that you do this on your production server without testing elsewhere, first.

It is also possible that there are dependencies in your schema that may make restoring a single table much more difficult... such as foreign keys referencing the table. You might have to modify the resulting SQL file to get the data back in, but this situation would exist even if you had a mysqldump file of the individual tables you're needing to restore.

But for the task at hand, the first two tools that came to mind are Perl and sed, both of which are free and available for Windows. Either one should do what you need.

We can find the range of lines we're interested in by displaying the line numbers of strategically-placed SQL comments mysqldump adds to the file:

The numbers at the left are line numbers in the dump file (we just now calculated them). So, if we wanted to restore mediawiki.image we need lines 272 through 301 to drop and re-create the table ... and 302 through 311 to restore the data.