I suppose since it's just an option in a client program, it can be added even after 10.0.5, setting to 10.0.6 for now.

Alexey pointed me to a recent bug with mysqldump --innodb-optimize-keys in Percona Server, where incorrect CREATE TABLE statement for partitioned tables are produced, it has not been fixed yet:
https://bugs.launchpad.net/percona-server/+bug/1233841

This is a diff against 10.0, it contains just the changes needed for mysqldump from the Percona 5.5 code and two other tiny changes, an update to the man page and the addition of the warning for the duplicate index in the test result. Attribution may also be needed.

added:
mysql-test/r/percona_mysqldump_innodb_optimize_keys.result
mysql-test/t/percona_mysqldump_innodb_optimize_keys.test
modified:
client/client_priv.h
client/mysqldump.c
man/mysqldump.1

This would still have this bug - https://bugs.launchpad.net/percona-server/+bug/1233841

The above bug is fixed.

http://lists.askmonty.org/pipermail/commits/2015-May/007813.html

http://lists.askmonty.org/pipermail/commits/2015-July/008193.html

Could you review this again, as I had to rewrite internal parser to support unquoted identifiers
and multi-column keys.

MySQL has the same feature request:
http://bugs.mysql.com/bug.php?id=49120

Maybe the problem would be simply solved by using a special "bulk load" mechanism when executing a transaction that performs the first insert into an empty table or partition. This could be part of MDEV-515.

Wouldn't it be better for InnoDB to support ALTER TABLE DISABLE/ENABLE KEYS that mysqldump already uses around inserts anyway?

A simple solution could be done purely in ha_innodb.cc, by dropping indexes on ALTER TABLE DISABLE KEYS and recreating them online on {{ALTER TABLE ENABLE KEYS. This won't require InnoDB to support disabled indexes and for an empty table dropping is fast.

The scope of MDEV-515 was reduced, and MDEV-24621 was filed for optimizing index creation during an insert into an empty table. With that, I think that a LOAD DATA statement should do the right thing.

Unfortunately, currently mysqldump may generate multiple INSERT statements per table. Only the first INSERT statement into an empty table would be optimized by MDEV-515 and MDEV-24621. Could we change that to LOAD?

The default mysqldump is with --opt, implying --extended-insert, so one INSERT per table. It can be configured otherwise. (up until the max-packet-size - default 24M)

For LOAD DATA we'd need the mariadb client (or server - mysqldump isn't strictly for the consumption of mysql/mariadb client) to recognize a an inline version of LOAD DATA. Otherwise some form of multiple files like https://github.com/maxbube/mydumper/commits/master (that seems to be getting activity again).

In MDEV-24818 we hacked the code so that a multi-statement INSERT transaction from mysqldump will be accelerated using the MDEV-515 mechanism. The data loading can be accelerated seriously further by MDEV-24621.

The Description feels a bit outdated.

git show mariadb-10.0.20:storage/innobase/include/univ.i|grep VERSION|head -3

#define INNODB_VERSION_MAJOR	5

#define INNODB_VERSION_MINOR	6

#define INNODB_VERSION_BUGFIX	25

MariaDB 10.0.20 claims to be based on the InnoDB from MySQL 5.6.25. That version includes Alter_inplace_info::RECREATE_TABLE, which had been added in MySQL 5.6.13 to support OPTIMIZE TABLE using the WL#6255 InnoDB online table rebuild algorithm whose original version was released as part of MySQL 5.6.8.

I think that the last missing piece to speed up data loading is MDEV-16281, to implement the multi-threaded creation of index trees.

Note: To benefit from MDEV-24621, a special option --no-autocommit needs to be specified to mariadb-dump until MDEV-32250 makes it the default.