Warning: this post describes practices that rely on side effects and may provide unstable results.
I was asked how to treat a table in MySQL as a stack and pop oldest entry from it. Of course there is always traditional approach – you lock table, fetch oldest record, delete it, commit. It isn’t that fun, though. This is what I came up to (and had multiple corrections):
mysql> delete from jobs where (@id:=jobs_id) limit 1; select @id; Query OK, 1 row affected (0.00 sec) +------+ | @id | +------+ | 3 | +------+ 1 row in set (0.00 sec) mysql> delete from jobs where (@id:=jobs_id) limit 1; select @id; Query OK, 1 row affected (0.00 sec) +------+ | @id | +------+ | 4 | +------+ 1 row in set (0.00 sec)
In case of transactions used, you’d need to commit as fast as you can, as DELETE would acquire locks (but that’s the price of ACID ;-) – concurrent pops are not that easy.
Appending to stack is easy though – just.. INSERT. If you do not want transactions, you would still want InnoDB and that is where side issues kick in.
InnoDB stores all records clustered together with primary key, so table scans also happen in order of PK. If you would apply ORDER BY, there would be no guarantee that MySQL would not do filesort (if it would always pick indexes, this method would be even more awesome ;-). In case of filesort, last @a value would be set before actually sorting the data set, so a different value would be returned than deleted.
MyISAM doesn’t care at all about order, unless you specify it to. Doing the pop trick without ORDER BY would treat the stack just as pool of records and would delete any single row (and return it of course). Adding ORDER BY would set @values again to pre-filesort state.
That reminds me another trick (has been floating around for a while), that allows atomic incrementing of a field and fetching a value:
mysql> update counters set counter_value=(@val:=counter_value+1); select @val;
-> update counters set counter_value=(@val:=counter_value+1); select @val;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
+------+
| @val |
+------+
| 562 |
+------+
1 row in set (0.00 sec)
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
+------+
| @val |
+------+
| 563 |
+------+
1 row in set (0.00 sec)
Yet another warning: As it’s modifying same row, only one transaction would be able to edit the record. So this should be done either not in transaction, or on HEAP/MyISAM/Blackhole engines.
