关注大学生就业,培养泛IT高端人才

陕西新榜样官方网站

您的位置: 主页 > 新闻动态 > 公司动态 >

InnoDB数据表与死锁

来源:西安JAVA培训 发布时间:2017-10-13 浏览量:

  InnoDB类型的数据表是最容易产生死锁问题的东西之一,因为它本身是一个索引工具的特性,导致了在检索问题的时候极易出现逻辑死循环,然后你就被锁住了,那么该如何处理这个问题?

  我们首先来看看 InnoDB 类型的数据表,只要能够解决索引问题,就可以解决死锁问题。MySQL 的 InnoDB 引擎是行级锁,需要注意的是,这不是对记录进行锁定,而是对索引进行锁定。在 UPDATE、DELETE 操作时,MySQL 不仅锁定 WHERE 条件扫描过的所有索引记录,而且会锁定相邻的键值,即所谓的 next-key locking。

  InnoDB 类型的数据表执行时,MySQL 会使用 KEY_TSKTASK_MONTIME2 索引,因此首先锁定相关的索引记录,因为 KEY_TSKTASK_MONTIME2 是非簇索引,为执行该语句,MySQL 还会锁定簇索引(主键索引)。

  假设“update TSK_TASK set STATUS_ID=1067,UPDATE_TIME=now () where ID in (9921180)”几乎同时执行时,本语句首先锁定簇索引 (主键),由于需要更新 STATUS_ID 的值,所以还需要锁定 KEY_TSKTASK_MONTIME2 的某些索引记录。

  这样第一条语句锁定了 KEY_TSKTASK_MONTIME2 的记录,等待主键索引,而第二条语句则锁定了主键索引记录,而等待 KEY_TSKTASK_MONTIME2 的记录,这样死锁就产生了。

  我们通过拆分第一条语句解决了死锁问题:即先查出符合条件的 ID:select ID from TSK_TASK where STATUS_ID=1061 and MON_TIME < date_sub(now(), INTERVAL 30 minute);然后再更新状态:update TSK_TASK set STATUS_ID=1064 where ID in (….)。

  我们发现,死锁虽然是较早就被发现的问题,但是很多情况下我们设计的程序里还是经常发生死锁情况。我们不能只是分析如何解决死锁这类问题,还需要具体找出预防死锁的方法,这样才能从根本上解决问题。

  免责声明:本文来源于网络,由网友提供或网络搜集,仅供个人研究、交流学习使用,不涉及商业盈利目的。如有版权问题,请联系本站管理员予以更改或删除。新榜样会定期发布西安IT培训等相关资料文章,包括西安JAVA培训陕西UI培训WEB开发培训网络营销工程师培训等领域,敬请关注!

  更多相关西安JAVA培训资讯,请点击: www.xinbangyang.com

IT培训 服务