Binlog Table Map Event to be a Sequential Index

The mapping defined by a binary log Table map log event can be slightly revamped to improve slave efficiency.

Currently, when a transaction is binlogged using binlog_format=ROW, a Table map event is written in the binary log to declare a table that the transaction is updating, and includes information to identify this table on the slave. In particular, this information includes an identification number (table_id) that is used by {{Rows log event}}s in this transactions, which specifies that the given row event is targeting that given table. This table_id is only applicable for the server which actually logged the event, and is generally meaningless to the slave for execution, outside of its use to identify the table to target. However, when the slave uses this table_id to identify a table, it does so by searching/iterating through a list of all tables targeted by the transaction.

This search for a table can be optimized by changing the assignment strategy of the table_id to effectively work as an index into the list of tables targeted by the transaction. That is, instead of using the actual table_id of the given table on the master server, the value can be filled in using some 0-indexed counter. Then when the slave needs to find the table that a given row event is targeting, it would use this index to simply access the table directly (rather than iteratively search). For example, the table maps would look like

Before this optimization:

Table_map: `test`.`t1` mapped to number 39

Table_map: `test`.`t2` mapped to number 55

Table_map: `test`.`t3` mapped to number 71

After this optimization:

Table_map: `test`.`t1` mapped to number 0

Table_map: `test`.`t2` mapped to number 1

Table_map: `test`.`t3` mapped to number 2