For the records, I finally managed to load my dump into Acquia Dev Desktop after renaming the file to .sql and specifying/using exactly the same database name as the original database name.
I don't know what caused the original issue or what solved it, since I don't believe the database name should be an issue at all.
Each data node's redo log has a number of 'parts' - currently 4 by default. Each redo log part is like a mini redo log, with 1 / Num_parts of the capacity defined for 'Redo log'. This design increases file system and lower layers parallelism when writing the redo log, but requires balance across the parts to be reasonable.
When a table is created, table fragments are created on each data node. Each fragment is assigned a redo log part which will be used to log all of the activity on the fragment - e.g. inserts, updates, deletes.
A table with only a single fragment on a particular data node will use only one redo log part, and you will see an imbalance in the use of the redo log parts as you have shown.
Where a table has multiple fragments stored on a data node, they will use different redo log parts, and the use of the different parts is balanced.
Where you have more than one table, the fragments of other tables will use different redo log parts, and the use of different parts will be statistically balanced.
So try creating the single table with more fragments (increase MAX_ROWS, or specify PARTITIONS=X in the CREATE TABLE statement), and see if the redo log part usage is more balanced.
Best Answer
I have dealt with questions like this in both directions
Mar 20, 2013: How can I determine the size of a dump file prior to dumping?May 21, 2012: How large will a MySQL database be relative to the dump file?Your question is a little different because you did not give anything about the target MySQL Instance (what Storage Engine will be used, which columns are TEXT/BLOB, what indexing is needed for your data, etc.)
IMHO the most straightforward way I can think of is the following
METHOD #1
Write some Perl/Python script to sum the length of all XML tag delimiters. Subtract the sum you get from the length of the file. That would essentially be the size of a CSV file less delimiters. This would be the bytes of the raw data.
METHOD #2
Do METHOD #1 and also take the count of all XML tag delimiters and add that count to the result of METHOD #1. That would like adding commas back into a CSV file. This make be closer in size to an actual CSV should you print the output to such a file.