一個 MySQL 表可以看作是一個隊列,每一行為一個元素。每次查詢得到滿足某個條件的最前面的一行,並將它從表中刪除或者改變它的狀態,使得下次查詢不會得到它。在沒有並發訪問的情況下,簡單地用 SELECT 得到一行,再用UPDATE(或者DELETE)語句修改之,就可以實現。
複製代碼 代碼如下:SELECT * FROM targets WHERE status='C' LIMIT 1;
UPDATE targets SET status='D' WHERE id='id';
如果有並發訪問,在SELECT和UPDATE語句之間可能會存在其他地SELECT查詢,導致同一行被取出多次。為了保證在並發情況下仍然能正常工作,一種思路是使用資料庫地鎖來防止,就像在多線程環境下所做地一樣。總之,要是的查詢和修改為一個原子操作,不被其它的訪問幹擾。MySQL 5 支援預存程序,可以用它來實現。
單條 UPDATE 語句應該原子操作的,可以利用這個特性來保證並發訪問情況下隊列的正常工作。每次取元素時,先用 UPDATE 修改合格第一行,然後再得到該行。可惜 UPDATE 語句沒有傳回值,重新用普通的SELECT的話又很難找到剛被改過的那條記錄。
這裡用到一個小技巧:在 UPDATE 時加上 id=LAST_INSERT_ID(id),再用 SELECT LAST_INSERT_ID() 即可得到剛修改的那條記錄的id。還有一個問題,當表中不存在合格記錄,導致 UPDATE 失敗時,LAST_INSERT_ID() 會保留原來地值不變,因而不能區分隊列中是否還有元素。
ROW_COUNT() 返回上一個語句影響的行數,把它作為 SELECT 的一個條件,可以協助解決這個問題。
最後,支援並發訪問的完整解決方案為:
複製代碼 代碼如下:UPDATE targets SET status='D', id=LAST_INSERT_ID(id) WHERE status='C' LIMIT 1;
SELECT * FROM targets WHERE ROW_COUNT()>0 and id=LAST_INSERT_ID();
更新:在實現帶優先順序的隊列時這種方法有問題,帶有 ORDER BY ... 條件的 UPDATE 語句非常慢,例如:
複製代碼 代碼如下: UPDATE targets SET status='D' WHERE status='C' ORDER BY schedule ASC LIMIT 1;
而單獨查詢和更新則是很快的: 複製代碼 代碼如下:SELECT id FROM targets WHERE status='C' ORDER BY schedule ASC LIMIT 1;
UPDATE targets SET status='D' WHERE id='id';
原來這是MySQL的Bug-12915,一年多以前提出來的,雖然關閉了,卻只解決了部分問題,尚不支援WHERE,見MySQL 5.0.15 的 Changlog。無奈,上面這種巧妙的方法也沒有實用價值了。
最後採用了一種折衷方案,如下:
複製代碼 代碼如下:UPDATE targets, (SELECT id FROM targets WHERE status='C' AND schedule<CURRENT_TIMESTAMP ORDER BY schedule ASC LIMIT 1) tmp SET status='D' WHERE targets.id=LAST_INSERT_ID(tmp.id);
SELECT * FROM targets WHERE ROW_COUNT()>0 and id=LAST_INSERT_ID();