Some storage engine features you only get if you’re InnoDB

I had reason to look into the extended secondary index code in MariaDB and MySQL recently, and there was one bit that I really didn’t like.


share->set_use_ext_keys_flag(legacy_db_type == DB_TYPE_INNODB);


use_extended_sk= (legacy_db_type == DB_TYPE_INNODB);

In case you were wondering what “legacy_db_type” actually does, let me tell you: it’s not legacy at all, it’s kind of key to how the whole “metadata” system in MySQL works. For example, to drop a table, this magic number is used to work out what storage engine to call to drop the table.

Now, these code snippets basically kiss goodbye to the idea of a “pluggable storage engine” architecture. If you’re not InnoDB, you don’t get to have certain features. This isn’t exactly MySQL or MariaDB encouraging an open storage engine ecosystem (quite the opposite really).

Having the MySQL server have this incredibly basic, busy and incomplete understanding of metadata has always been a bit of a mess. The code for reading a table definition out of the FRM file really does show its age, and has fingers all through the server.

If somebody was serious about refactoring server code, you’d certainly be looking here, as this code is a major source of arbitrary limitations. However, if you have the server and the engine(s) both having separate views of what is the “correct” state of metadata you end up with a mess (anyone who has had InnoDB be out of sync with FRMs knows this one). I worry that the FRM code will be replaced with something even less understandable by humans, again making the mistake that the server knows the state of the engine better than the engine does.

See Also:

16 thoughts on “Some storage engine features you only get if you’re InnoDB

  1. We are not happy with the MariaDB and MySQL implementations of extended keys because we had to patch the open_binary_frm function to add TOKUDB to the list of storage engines that support extended keys. This is a hack. IMO, the extended keys code in MariaDB and MySQL 5.6 should be redone to query the storage engine to see if it supports extended keys. Until that is done, TokuDB requires the same extended keys patch as InnoDB.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.