I think I have a plausible explanation you find very intriguing.

When you loaded the MyISAM table, only one index got loaded into the .MYI file in a lopsided manner.

Which index would that be ? THE PRIMARY KEY. Why ?

Indexes usually use BTREEs. They are designed to collect keys into a single BTREE node and balance the BTREE internally until the BTREE is full. On the insert into the full node, the full tree node is split and the keys inside are divided.

Most often a BTREE node will split is when you load the keys in order. For proof, look at the worst case BTREE --- the balanced binary tree.

I have several posts in the DBA STackExchange where I mention how a balanced binary only has node with one key. I also mention how a leaf pages must rebalance about 45% of the time when inserting a new key. Here are those posts:

• Aug 03, 2011 : When should I rebuild indexes?
• Jun 28, 2012 : Benefits of BTREE in MySQL
• Oct 26, 2012 : How badly does innodb fragment in the face of somewhat out-of-order insertions?
• Nov 26, 2012 : Does the Int type primary key insert order affect query performance in MySQL?
• Jun 04, 2013 : Why would increase in innodb_buffer_pool_size slow down MySQL?

My working theory is that random inserts into the table may actually make the .MYI smaller by prevent tree node splits as much as possible.

In order to make this happen, you will have to something quite unusual. Ready for this ?

ALTER TABLE generic_dummy_table_name ORDER BY datetime;

or

ALTER TABLE generic_dummy_table_name ORDER BY user,datetime;

That right, you can reorder the physical rows of the table. This may make the indexes a different size by inducing BTREE splits on another index.

Try reordering the table. Then, mysqldump it and reload it. You may find that the .MYI may get smaller or bigger. You cannot really predict it.

Next time, try reloading the MyISAM table with a very large bulk insert buffer.

Just run

SET GLOBAL bulk_insert_buffer_size = 1024 * 1024 * 1024;

then connect to mysql and reload the mysqldump.

GIVE IT A TRY !!!

Good luck. You'll need to do way more work than just a "restore".

Essentially, you'll need to create a custom pipe to convert the data in the SQL Server database into the table structure used by WordPress.

Even if the table structure was identical, and it isn't, you can't "restore" a .bak file into a MySQL database. The .bak does not contain SQL statements; it is a binary representation, page by page, of the SQL Server database.

Presuming there aren't a huge number of articles, it is generally considered easier to manually transfer them into WordPress using the interface. Welcome to the thrill of vendor lock-in.

If you have access to a SQL Server, you might try restoring the .bak file then exporting the desired data as SQL Statements using the "script database" facility. You might then be able to do a transformation on the SQL Statements to make them "fit" the design of the WordPress database. I'd be very skeptical that this would be easy, however at a certain point this will take less time than manually recreating the stories in WordPress.