Mysql InnoDB 排他锁
用法: select … for update;
例如:select * from goods where id = 1 for update;
排他锁的申请前提:没有线程对该结果集中的任何行数据使用排他锁或共享锁,否则申请会阻塞。
for update仅适用于InnoDB,且必须在事务块(BEGIN/COMMIT)中才能生效。在进行事务操作时,通过“for update”语句,MySQL会对查询结果集中每行数据都添加排他锁,其他线程对该记录的更新与删除操作都会阻塞。排他锁包含行锁、表锁。
1、InnoDB行锁是通过给索引上的索引项加锁来实现的,只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁。
2、由于MySQL的行锁是针对索引加的锁,不是针对记录加的锁,所以虽然是访问不同行的记录,但是如果是使用相同的索引键,是会出现锁冲突的。应用设计的时候要注意这一点。
3、当表有多个索引的时候,不同的事务可以使用不同的索引锁定不同的行,另外,不论是使用主键索引、唯一索引或普通索引,InnoDB都会使用行锁来对数据加锁。
4、即便在条件中使用了索引字段,但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的,如果MySQL认为全表扫描效率更高,比如对一些很小的表,它就不会使用索引,这种情况下InnoDB将使用表锁,而不是行锁。因此,在分析锁冲突时,别忘了检查SQL的执行计划,以确认是否真正使用了索引。
5、检索值的数据类型与索引字段不同,虽然MySQL能够进行数据类型转换,但却不会使用索引,从而导致InnoDB使用表锁。通过用explain检查两条SQL的执行计划,我们可以清楚地看到了这一点。
最近发现很多人被类似秒杀这样的设计困扰,其实这类问题可以很方便地解决,先来说说这类问题的关键点是什么:
- 一定要高性能,不然还能叫秒杀吗?
- 要强一致性,库存只有100个,不能卖出去101个吧?但是库存10000实际只卖了9999是否允许呢?
- 既然这里说了是秒杀,那往往还会针对每个用户有购买数量的限制。
总结一下,还是那几个词:高性能强一致性!
下文的所有解决方案是在 Mysql InnoDB 下做的。因为用到了很多数据库特性。其他的数据库或其他的数据库引擎会有不同的表现,请注意。
完全不考虑一致性的方案
表结构
+-----------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+------------------+------+-----+---------+----------------+
| id | int(11) unsigned | NO | PRI | NULL | auto_increment | | user_id | int(11) | NO | | NULL | | | deal_id | int(11) | NO | | NULL | | | buy_count | int(11) | NO | | NULL | | +-----------+------------------+------+-----+---------+----------------+
方案
表结构很简单,其实就是一个user
和deal
的关联表。谁买了多少就插入数据呗。
首先,还要检查一下传过来的buy_count
是否超过单人购买限制。
接下来,每次插入前执行以下以下操作检查一下是否超卖即可:
select sum(buy_count) from UserDeal where deal_id = ?
最后还要检查一下这个用户是否购买过:
select count(*) from UserDeal where user_id = ? and deal_id = ?
全都没问题了就插入数据:
insert into UserDeal (user_id, deal_id, buy_count) values (?, ?, ?)
存在的问题
大家别笑,这样的设计你一定做过,刚毕业的时候谁没设计过这样的系统啊?而且大部分系统对性能和一致性的要求并没有那么高,所以以上的设计方案还真是普遍存在的。
那就说说在什么情况下会出问题吧:
- 如果库存只剩一个,两个用户同时点购买,两个人检查全部成功,最后,就超卖了。
- 如果一个用户同时发起两次请求,检测部分同样可能会同时通过,最后,数据就异常了。
那就让我们一步步来解决里面存在的问题吧。
保证单用户不会重复购买
先来解决最简单的问题,保证单用户不会重复购买。
其实只要利用数据库特性即可,让我们来加一个索引:
alter table UserDeal add unique user_id_deal_id(user_id, deal_id)
加上唯一索引后,不仅查询性能提高了,插入的时候如果重复还会自动报错。
当然别忘了在业务代码中 catch 一下这个异常,并在页面上给用户友好的提醒。
解决超卖问题
方案
为了解决这个问题,第一个想到的就是把这几次操作在事务中操作。否则无论怎么改,也都不是原子性的了。
但是加完事务后就完了?
上面的select
语句没有使用for update
关键字,所以就算加入了事务也不会影响其他人读写。
所以我们只要改一下select
语句即可:
select sum(buy_count) from UserDeal where deal_id = ? for update
优化
刚改完后发现,问题解决了!so easy!步步高点读机,哪里不会点哪里,so easy!
但是不对啊!为什么两个用户操作不同的deal
也会相互影响呢?
原来我们的select
语句中的查询条件是where deal_id = ?
,你以为只会锁所有满足条件的数据对吧?
但实际上,如果你查询的条件不在索引中,那么 InnoDB 会启用表锁!
那就加一个索引呗:
alter table UserDeal add index ix_deal_id(deal_id)
提高性能了
好了,到目前为止,无论用户怎没点,无论多少个人买同一单,都不会出现一致性的问题的。
而且事务都是行锁,如果你的业务场景不是秒杀,操作是分散在各个单子上的。而且你的压力不大,那么优化到这就够了。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)