激活码发放，高并发下如何解决可能出现的异常。

现在有个发放激活码的系统，php+mysql。
code表：
id（主键自增长），code（激活码内容，如123abc），status（1代表未被发放，0代表已被发放）。

现在有很多用户（注册用户，能拿到用户信息）去抽这些激活码，每人每天只能抽1次，这一次是肯定能抽到的。

每当用户抽一次激活码，就找到一行status为1的激活码记录，把这行记录的status置为0，同时在record表里添加一行记录（用户id和激活码id），然后返回激活码内容给用户。

逻辑挺简单，现在我要解决的问题是，就是高并发情况下可能会有问题：

比如很多用户同时抽激活码，我select一行status为1的激活码记录时，可能多个用户会select到同一个激活码。有没有什么办法当某个请求select一行记录时，就把这行记录锁住，包证其他请求不会拿到这个激活码。

希望各位大神帮我分析下我这种逻辑在高并发下可能会出现什么问题，有什么解决方案？因为我现在做的项目实际上会遇到高并发的情况，所以必须考虑进去。。。

----------补充----------
谢谢大家的答案， 我会一一参考的。另外可能没说清楚，激活码是提前生成好的，数量和内容都是固定的，提前插入进数据库。

回复内容：

现在有个发放激活码的系统，php+mysql。
code表：
id（主键自增长），code（激活码内容，如123abc），status（1代表未被发放，0代表已被发放）。

现在有很多用户（注册用户，能拿到用户信息）去抽这些激活码，每人每天只能抽1次，这一次是肯定能抽到的。

每当用户抽一次激活码，就找到一行status为1的激活码记录，把这行记录的status置为0，同时在record表里添加一行记录（用户id和激活码id），然后返回激活码内容给用户。

逻辑挺简单，现在我要解决的问题是，就是高并发情况下可能会有问题：

比如很多用户同时抽激活码，我select一行status为1的激活码记录时，可能多个用户会select到同一个激活码。有没有什么办法当某个请求select一行记录时，就把这行记录锁住，包证其他请求不会拿到这个激活码。

希望各位大神帮我分析下我这种逻辑在高并发下可能会出现什么问题，有什么解决方案？因为我现在做的项目实际上会遇到高并发的情况，所以必须考虑进去。。。

----------补充----------
谢谢大家的答案， 我会一一参考的。另外可能没说清楚，激活码是提前生成好的，数量和内容都是固定的，提前插入进数据库。

建议使用redis，速度也快,每天定时再将数据落地到数据库

Redis 本身提供的所有 API 都是原子操作

1、select id, code from XXX where status ＝ 0 limit 1；然后更新的时候记得带上条件，update XXX set status ＝ 1 where id = #id# and status = 0;如果update失败，那么重新select，然后update，如此循环。

2、一种方式用队列，取一条记录的同时等于删除了这条记录，redis可以实现。

在项目里面建一个文件，

1. 先判断这个文件是否被锁
2. 锁定的话就等待，没被锁定的话就给文件加锁
3. 拿到锁之后读数据库
4. 执行完操作后给文件解锁

这样做只解决了互斥的问题，但是并没解决高并发的问题，建议题主试试redis队列

这个需要楼主把code表的存储引擎设置为Innodb的，然后搜索下mysql innodb 事务隔离级别。
推荐一篇文章
http://imysql.cn/2008_07_10_innodb_tx_isolation_and_lock_mode

一般不推荐直接在DB上做这种事务隔离处理，一般是在应用中处理的。

InnoDB 行锁 + 事务,

Start Transaction; 
Select * From `xxx` Where `id` = 123456 for Update;
Update `xxx` Set status = 0 Where `id` = 123456;
Commit;

这里id必须为主键。否则会导致全表锁死
也可以后端逻辑里用cache做一个队列，异步传达结果

参考楼上的 InnoDB 行锁 就够了 可以不用事务吧
判断一下 update set 的返回值 也就知道是否有更新成功了 如果没有影响任何记录行 就知道更新无效了

正常来说

@白菜哥永远都是大白菜 的答案应该满足需求了。

不过我仔细想了下，楼主的需求在查询的时候应该是不知道主键的，sql应该更像是

select * from xxx where status=1 limit 1;这种。

所以高并发的事务select的应该都是同一行。只有等第一个事务完成update后才会全部select到下一行。
所以效果实际上等同表锁？哈，我也不太懂细节，这个问题比较有意思，我决定作为一个实验列在todo list里面。

回到楼主的问题，我更喜欢在代码层面上做个生产消费队列。

除了楼上各位说的InnoDB行锁外，从数据库中select一条激活码时可以根据用户ID简单的做一下处理：
offset = user_id % 30;
SELECT * FROM table WHERE XXX LIMIT offset,1;

这样并发取同一条激活码的可能性就更低了，减少了等待锁的时间。