A co-worker just made me aware of a very strange MySQL behavior.
Assuming you have a table with an auto_increment field and another field that is set to unique (e.g. a username-field). When trying to insert a row with a username thats already in the table the insert fails, as expected. Yet the auto_increment value is increased as can be seen when you insert a valid new entry after several failed attempts.
For example, when our last entry looks like this...
ID: 10
Username: myname
...and we try five new entries with the same username value on our next insert we will have created a new row like so:
ID: 16
Username: mynewname
While this is not a big problem in itself it seems like a very silly attack vector to kill a table by flooding it with failed insert requests, as the MySQL Reference Manual states:
"The behavior of the auto-increment mechanism is not defined if [...] the value becomes bigger than the maximum integer that can be stored in the specified integer type."
Is this expected behavior?
InnoDB
is a transactional engine.
This means that in the following scenario:
Session A
inserts record 1
Session B
inserts record 2
Session A
rolls back, there is either a possibility of a gap or session B
would lock until the session A
committed or rolled back.
InnoDB
designers (as most of the other transactional engine designers) chose to allow gaps.
From the documentation:
When accessing the auto-increment counter,
InnoDB
uses a special table-levelAUTO-INC
lock that it keeps to the end of the currentSQL
statement, not to the end of the transaction. The special lock release strategy was introduced to improve concurrency for inserts into a table containing anAUTO_INCREMENT
column…
InnoDB
uses the in-memory auto-increment counter as long as the server runs. When the server is stopped and restarted,InnoDB
reinitializes the counter for each table for the firstINSERT
to the table, as described earlier.
If you are afraid of the id
column wrapping around, make it BIGINT
(8-byte long).