Convert SQL to CSV

Usually you are not really asking for SQL to CSV

You have been handed a .sql file. Perhaps it came out of a hosting control panel labelled backup, perhaps a developer sent it, perhaps it fell out of a WordPress export. It will not open in anything useful, it is far too long to read, and the actual question is simpler than conversion: what is in this thing?

So that is what happens first. Drop the file and every table in it is listed by name with its row count and its columns — before any choice about output format. Nine times out of ten that list is the answer on its own, because the moment you can seewp_users sitting next to wp_postmeta, you know which one you wanted. Exporting the columns you tick is just what you do next.

Pulling three columns out of one table

This is the request underneath most visits: get the names, email addresses and phone numbers out of the contact form table and into something openable. It is not a separate feature here and it deliberately does not have a button of its own. Once the table is on screen with its column names, untick the fifteen columns you do not care about and the file contains three.

That framing matters because the alternative — a tool that offers to extract contacts — would have to guess which columns those are, and it would guess from column names invented by whoever wrote the plugin. Showing you the table and letting you point is both simpler and more likely to be right.

If the addresses are scattered through the file rather than sitting in a column of their own — in a serialised settings blob, say, or a comments table — theemail extractor reads the same dump and pulls out every address in it, also without uploading anything.

Why the file is tokenized instead of pattern-matched

The tempting shortcut is a regular expression along the lines of INSERT INTO .+ VALUES (.+);. It works on the example you tested it with and fails on the first real dump, silently, in four separate ways.

A semicolon inside a value ends the statement early and half the row vanishes. A bracket inside a value throws off the bracket counting. A comma inside a value splits one cell into two, shifting every column after it. And an apostrophe escaped as\' — legal in MySQL, not in PostgreSQL — ends the string for any reader that does not know which engine wrote the file. Every one of those produces output that looks fine at a glance. Here the file goes through a real tokenizer first, so quoting, comments and escapes are already resolved before a single row is read, and the dialect is named on screen with the evidence that suggested it.

What a mysqldump throws at a reader

It is the most common kind of file people bring, and it is full of things that are not SQL as anyone writes it by hand. Identifiers in backticks. ENGINE=InnoDBtrailing the table definition. Comments in the form /*!40101 … that are comments to every engine except MySQL, which executes them. AndINSERT statements with no column list at all, because that is the default — so the column names have to be recovered from the CREATE TABLE hundreds of lines earlier.

Index definitions inside that CREATE TABLE are skipped rather than counted. Miss that and your CSV arrives with two extra columns called PRIMARY andKEY, which is exactly the sort of nonsense that makes people give up on the file and email it to somebody instead.

Getting it to open cleanly in Excel

Keep the byte order mark, which is on by default. Without it Excel reads the file in its local code page and every accented character arrives mangled — the single most common complaint about CSV exports anywhere. If your Excel is a Swedish, German or French install, switch the separator to a semicolon too: those versions expect it, and a comma-separated file lands entirely in column A.

One thing a CSV cannot fix is Excel's habit of reinterpreting values on import. Long IDs become scientific notation and leading zeros disappear, whatever the encoding says, because that happens after the file is read. If your table has either, take the workbook export instead — every cell there is typed, so nothing gets reinterpreted.

A dump is the most sensitive file you own

Not a document. Every row of every table: the customers, the addresses, the order history, the password hashes, the API keys somebody stored in a settings table. There is no upload endpoint here, and you can verify that in the network panel while you drop the file. Nothing is refused for its size either, and the reading runs off the main thread so a large backup does not lock up the page while it is parsed.