可以这样理解Mysql中的查询操作：

一个 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 sche

dule 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

SELECT * FROM targets WHERE ROW_COUNT()>0 and id=LAST_INSERT_ID();