My attention was drawn to this stellar new feature in MySQL:
The DELAYED option for the INSERT statement is a MySQL extension to standard SQL that is very useful if you have clients that cannot or need not wait for the INSERT to complete. This is a common situation when you use MySQL for logging and you also periodically run SELECT and UPDATE statements that take a long time to complete.
When a client uses INSERT DELAYED, it gets an okay from the server at once, and the row is queued to be inserted when the table is not in use by any other thread.
O...K... So alarm bells aren't already ringing.
The queued rows are held only in memory until they are inserted into the table. This means that if you terminate mysqld forcibly (for example, with kill -9) or if mysqld dies unexpectedly, any queued rows that have not been written to disk are lost.
Well, that's OK. I mean if you're using MySQL, you probably don't give a shit about your data anyway.
Anyway, there's a couple of other minor constraints:
# Because the INSERT DELAYED statement returns immediately, before the rows are inserted, you cannot use LAST_INSERT_ID() to get the AUTO_INCREMENT value that the statement might generate.
# DELAYED rows are not visible to SELECT statements until they actually have been inserted.
# Pending INSERT DELAYED statements are lost if a table is write locked and ALTER TABLE is used to modify the table structure.
Somehow, I expect huge swathes of people encountering random data losses in the world of MySQL from here on in.
5 comments:
The last time someone tried to make me use MySQL it didn't have even have transactions.
"I mean if you're using MySQL, you probably don't give a shit about your data anyway." qft
I wish you'd write something intellectually graspable by the vast majority of us. Could I throw bleach at it?
You might as well ... :o)
Here's one from left field.. but don't use insert delayed?
How about Foreign key constraints?
Does it check those before returning?
Post a Comment