First, you need to know what you are doing to InnoDB when you plow millions of rows into an InnoDB table. Let's take a look at the InnoDB Architecture.

![InnoDB Architecture][1]

In the upper left corner, there is an illustration of the InnoDB Buffer Pool. Notice there is a section of it dedicated to the insert buffer. What does that do ? It is ised to migrate changes to secondary indexes from the Buffer Pool to the Insert Buffer inside the system tablespace (a.k.a. ibdata1). By default, [innodb_change_buffer_max_size][2] is set to 25. This means that up to 25% of the Buffer Pool can be used for processing secondary indexes.

In your case, you have 6.935 GB for the InnoDB Buffer Pool. A maximum of 1.734 GB will be used for processing your secondary indexes.

Now, look at your table. You have 13 secondary indexes. Each row you process must generate a secondary index entry, couple it with the primary key of the row, and send them as a pair from the Insert Buffer in the Buffer Pool into the Insert Buffer in ibdata1. That happens 13 times with each row. Multiply this by 10 million and you can almost feel a bottleneck coming.

#SUGGESTIONS

###SUGGESTION #1

My first suggestion for importing this rather large table would be

- Drop all the non-unique indexes
- Import the data
- Create all the non-unique indexes

###SUGGESTION #2

Get rid of duplicate indexes. In your case, you have 

    KEY `party_id` (`party_id`),
    KEY `party_id_2` (`party_id`,`status`)

Both indexes start with `party_id`, you can increase secondary index processing by at least 7.6 % getting rid one index out of 13. You need to eventually run

    ALTER TABLE monster DROP INDEX party_id;

###SUGGESTION #3

Get rid of indexes you do not use. Look over your application code and see if your queries use all the indexes. You may want to look into [**pt-index_usage**][3] to let it suggest what indexes are not being used.

#EPILOGUE

Putting the first two suggestions in place, do the following:

- Drop the 13 non-unique indexes
- Import the data
- Create all the non-unique indexes except the `party_id` index

Perhaps the following may help

    CREATE TABLE monster_new LIKE monster;
    ALTER TABLE monster_new
      DROP INDEX `party_id`,
      DROP INDEX `creation_date`,
      DROP INDEX `email`,
      DROP INDEX `hash`,
      DROP INDEX `address_hash`,
      DROP INDEX `thumbs3`,
      DROP INDEX `ext_monster_id`,
      DROP INDEX `status`,
      DROP INDEX `note`,
      DROP INDEX `postcode`,
      DROP INDEX `some_id`,
      DROP INDEX `cookie`,
      DROP INDEX `party_id_2`;
    ALTER TABLE monster RENAME monster_old;
    ALTER TABLE monster_new RENAME monster;

Import the data into `monster`. Then, run this

    ALTER TABLE monster
      ADD INDEX `creation_date`,
      ADD INDEX `email` (`email`(4)),
      ADD INDEX `hash` (`hash`(8)),
      ADD INDEX `address_hash` (`address_hash`(8)),
      ADD INDEX `thumbs3` (`thumbs3`),
      ADD INDEX `ext_monster_id` (`ext_monster_id`),
      ADD INDEX `status` (`status`),
      ADD INDEX `note` (`note`(4)),
      ADD INDEX `postcode` (`postcode`),
      ADD INDEX `some_id` (`some_id`),
      ADD INDEX `cookie` (`cookie`),
      ADD INDEX `party_id_2` (`party_id`,`status`);

#GIVE IT A TRY !!!


  [1]: https://i.sstatic.net/X7UrX.jpg
  [2]: http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_change_buffer_max_size
  [3]: http://www.percona.com/doc/percona-toolkit/2.2/pt-index-usage.html