I ran into a fun variant of this last week with MySQL's patented “data integrity is for cowards” feature: someone incorrectly modeled a column as a signed (i.e. default) BIGINT(20) over a decade ago and populated it with the UUID_SHORT() function's output. UUID_SHORT() actually returns an <i>unsigned</i> BIGINT(20) so any value greater than 2^63 would be silently truncated.<p>The algorithm MySQL uses for generating these numbers starts with the server ID, which meant that the old database system ran for at least 13 years without issues — and the app immediately failed when I deployed it into AWS. RDS Aurora instances have server ID value much larger than the 1 digit values used by the old server and so all of these values had the first bit set. That meant that the first INSERT would “work”, completing without an error (statistically nobody checks warnings and this app was no different), but all subsequent INSERTs would fail because they overflowed to the same value as the first one. One quick ALTER TABLE on a 90GB table later to change it to BIGINT(20) UNSIGNED and everything was working again.<p>This could also produce some confusing errors: the first report I got was that the database wasn't working because the developer had log files showing the INSERT using a number obtained from an earlier SELECT UUID_SHORT() query being inserted but that value not being present in the table.