Fun MySQL fact of the day: auto_increment is mostly monotonic

On Friday, I left you with a cliff-hanger suggesting that foregoing the use of foreign key constraints can result in undetectable account/identity takeovers, data leakage, data loss, corruption, and so on, and so on. And it can. And not only by accident, but also by a really fun MySQL ... read more

Fun MySQL fact of the day: foreign keys are important

A Foreign Key is a table constraint that allows a database index to remain consistent based on the existence (or non-existence) of another row in a another table. For example, MySQL will prevent the removal of a referenced row until all other referencing rows have first been removed. It will ... read more

Fun MySQL fact of the day: necessarily coarse locks

If, like me, you're curious why, in yesterday's example, InnoDB acquires a next-key lock before and a gap lock after the records it is updating with equality in a secondary index when using REPEATABLE READ (what a mouthful!), then today's Fun MySQL fact is for you! I ... read more

Fun MySQL fact of the day: the phantom record menace

Yesterday, we created an index to prevent a full table scan from locking the entire list_of_things table during a single UPDATE. I mentioned it was an improvement to the problem, but not a complete fix. Today, we'll see why.  ... read more

Fun MySQL fact of the day: tenant lock-out

A couple weeks ago, we very briefly touched on the subject about MySQL/InnoDB locking only single records. And since we're on the topic of multi-tenant schemas, I think it's a good time to focus on this subject. For now, we'll focus on using MySQL's default ... read more

Fun MySQL fact of the day: REPLACE your expectations

So, if we agree that we should avoid using INSERT ... ON DUPLICATE KEY UPDATE and INSERT IGNORE, surely we can use REPLACE INTO to upsert a row, right?! And yes, you can, if you want a DoS bug feature or account/identity takeover vulnerability in your multi-tenant system. Yep, this ... read more

Fun MySQL fact of the day: IGNORE at your own peril

Yesterday, we saw how INSERT ... ON DUPLICATE KEY UPDATE can unknowingly result in not-completely-expected situations. To get around that, you may have thought to use INSERT IGNORE, instead. Often, INSERT IGNORE is used when attempting to insert a row that may already exist. The underlying expectation a developer often has ... read more


As developers, part of our job is ensuring system stability long after we are finished writing code. It is our responsibility to ensure the next developer in our place doesn't inherit a system littered with landmines and that our customers' data integrity and privacy is always a top priority ... read more

Fun MySQL fact of the day: implicit rollbacks

Last Thursday, I suggested that you may not always want your transactions automatically rolled-back on an ACID violation, and, on Monday, I hinted that transaction rollbacks are nearly the most expensive thing you can do in MySQL/InnoDB. And, well, it's because of the very same "undo logs" about ... read more

Fun MySQL fact of the day: too much history

Yesterday, we discussed that InnoDB stores "old" record versions in an undo log, but we didn't discuss where undo logs are stored. While it's amusing to think it's turtles all the way down, it's actually a lot simpler: undo logs are stored inside InnoDB (and in ... read more

1 2 3