Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
After MDEV-6076 introduces persistent AUTO_INCREMENT for InnoDB, InnoDB does not really require an index to exist on AUTO_INCREMENT columns.
The reason for requiring an index to exist was that before MDEV-6076, InnoDB used to execute the equivalent of SELECT MAX(autoinc_column) when loading a table definition.
After MDEV-6076, there only are two cases where we need MAX(autoinc_column). The first one is upgrading an old dataset where the persistent AUTO_INCREMENT is not present (but the AUTO_INCREMENT column is necessarily indexed, because up to now, InnoDB always required the index to exist).
The second reason is the following use case:
CREATE TABLE t (autoinc_column SERIAL);
|
INSERT INTO t SET autoinc_column=100;
|
ALTER TABLE t AUTO_INCREMENT = 1;
|
INSERT INTO t SET autoinc_column=NULL;
|
SELECT * FROM t;
|
By default, ALGORITHM=INPLACE would reset the sequence to 1, while after ALGORITHM=COPY, the last INSERT would use a value larger than 100.
For compatibility with ALGORITHM=COPY and MyISAM, the user-requested AUTO_INCREMENT=1 should be adjusted to be at least MAX(autoinc_column)+1.
If we want to maintain the ALTER TABLE compatibility, we could execute MAX(autoinc_column) on the SQL layer, using an index if one is available. The InnoDB internal code that requires the index to exist can be removed. Even if an index is not available, a table scan would be a lot faster than executing ALGORITHM=COPY.
Most of this work should be outside InnoDB. Maybe there should be a handler::table_flags() bit for specifying whether an index on AUTO_INCREMENT column is required.
Attachments
Issue Links
- is blocked by
-
MDEV-6076 Persistent AUTO_INCREMENT for InnoDB
- Closed