Bug #76392 Assume that index_id is unique within a tablespace, not within InnoDB
Submitted: 19 Mar 2015 16:23 Modified: 13 Apr 2015 17:37
Reporter: Marko Mäkelä Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:8.0.0 OS:Any
Assigned to: CPU Architecture:Any

[19 Mar 2015 16:23] Marko Mäkelä 
Description:
In InnoDB, index_id (PAGE_INDEX_ID) is globally unique for the InnoDB instance.
In principle, it should suffice to have index_id unique within an InnoDB tablespace.
For example, importing tablespaces would then be easier, because we would not need to worry about duplicate index_id, because each tablespace would have its own private set of index_id.

How to repeat:
Read the code.

Suggested fix:
Replace index_id_t lookups with lookups on global_index_id_t, which comprises space_id and index_id.

In the InnoDB adaptive hash index (rec_fold, dtuple_fold), replace index_id_t with global_index_id_t.
[26 Mar 2015 9:15] Marko Mäkelä 
Posted by developer:
 
This change does not affect our ability of storing indexes of a table in separate tablespaces.
We are only extending index_id_t from 1 to 2 components.
When looking up an index for a given table, the full index_id_t will have to be specified.
[13 Apr 2015 17:37] Daniel Price 
Posted by developer:
 
Fixed as of the upcoming 5.8.0 release, and here's the changelog entry:

For persistent tables, the internal unique identifier for "InnoDB"
indexes ("index_id") now includes a tablespace identifier
("space_id","index_id"). This change makes index identifiers unique at the
tablespace level as well as the "InnoDB" instance level, and supports
future work related to index identifier allocation.
[18 Jun 2016 21:25] Omer Barnir 
Posted by developer:
 
Reported version value updated to reflect release name change from 5.8 to 8.0