mysql数据库死锁 情景一

备注:CI的SQL构造器,若果数据是int类型的话必须用intval进行转换

有一张查询很频繁的表,然后尝试根据主键去更新某一个字段,SQL如下:

update node_bird set Isverify=1 where NodeID=‘912399‘;

发现NodeID原本是int,CI的sql构造器将NodeID生成SQL语句的时候加了单引号,然而这张表的查询比较多,导致后面的查询都死掉了

时间: 2024-10-27 08:15:09

mysql数据库死锁 情景一的相关文章

nagios 添加自定义监控项目监控mysql数据库死锁

nagios 添加自定义监控项目 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 系统环境:CentOS Linux release 7.2.1511 (Core) nagios 版本: 2.15 这里配合pt-dead-logger插件了,运行了这个插件,有死锁就会在test.deadlocks表写入死锁的信息 这里通过检测这个表是否增加了行数来发报警 nagios客户端自定义脚本: ###这里为了省事,直接把数据库的用户,

mysql数据库死锁的产生原因及解决办法

这篇文章主要介绍了mysql数据库锁的产生原因及解决办法,需要的朋友可以参考下 数据库和操作系统一样,是一个多用户使用的共享资源.当多个用户并发地存取数据 时,在数据库中就会产生多个事务同时存取同一数据的情况.若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性.加锁是实现数据库并 发控制的一个非常重要的技术.在实际应用中经常会遇到的与锁相关的异常情况,当两个事务需要一组有冲突的锁,而不能将事务继续下去的话,就会出现死锁,严 重影响应用的正常执行. 在数据库中有两种基本的锁类型

MySQL数据库死锁分析

背景说明: 公司内部一套自建分布式交易服务平台,在POC稳定性压力测试的时候出现了数据库死锁.(InnoDB引擎)由于保密性,假设是app_test表死锁了. 现象: 发生异常:Deadlock found when trying to get lock; try restarting transaction 分析思路: 1.回忆和查找相关资料,InnoDB死锁导致的原因. 第一:涉及多表访问,两个事务相互占有对方需要的锁.假设有A表(含有初始化记录1)和B表(含有初始化记录2).进行如下操作会

MySQL 数据库死锁

数据库死锁 死锁的解决办法(1) 执行下面SQL,先查看哪些表被锁住了: select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id; 查处引起死锁的会话 select b.username,b.sid,b.serial#,logon_time from vlocked_object a,vsession b

mysql数据库死锁

当我们频繁的对数据库进行插入或更新的时候,有可能会直接报sql错误1205:lock wait timeout exceeded.数据库的死锁. 一般INNODB数据库会自动添加事务,当进行插入或者更新的时候,如果上次commit尚未执行完,而又有一次新的commit提交的时候,系统就会报SQL错误1205:lock wait timeout exceeded.这就是mysql死锁. 作为一个新手,碰到这样苦逼的事情自然是手足无措.于是赶紧上网看看解决方案,不负所望,网上还真找到相应的结局方案,

记一次线上MySQL数据库死锁问题

最近线上项目报了一个MySQL死锁(DealLock)错误,虽说对业务上是没有什么影响的,由于自己对数据库锁这块了解不是很多,之前也没怎么的在线上碰到过.这次刚好遇到了,便在此记录一下. 出现死锁问题背景 项目层面:报错的项目做的是一个批量下单的动作,会同时写入多条订单数据,代码之前写的是一个事务中一个循环一条一条insert到数据库(至于为啥没用批量插入就不追究了,历史原因了). 数据库层面:一张test表(非线上真实表),比较重要的是有一个 type 和 name的唯一索引. 事务隔离级别:

Mybatis-update - 数据库死锁 - 获取数据库连接池等待

最近学习测试mybatis,单个增删改查都没问题,最后使用mvn test的时候发现了几个问题: update失败,原因是数据库死锁 select等待,原因是connection连接池被用光了,需要等待 get: 要勇于探索,坚持就是胜利.刚看到错误的时候直接懵逼,因为错误完全看不出来,属于框架内部报错,在犹豫是不是直接睡觉得了,毕竟也快12点了.最后还是给我一点点找到问题所在了. 同上,要敢于去深入你不了解的代码,敢于研究不懂的代码. 距离一个合格的码农越来越远了,因为越学越觉得漏洞百出,自己

MySQL数据库事务各隔离级别加锁情况--read uncommitted篇(转)

本文转自https://m.imooc.com/article/details?article_id=17291,感谢作者 1.目的 1.1 合适人群 1.数据库事务特征我只是背过,并没有很深刻的理解. 2.数据库事务的隔离级别只是了解,并没有深刻理解,也没有在实际工作中体验使用过. 3.经常面试被人问起数据库加锁情况,一头雾水,很懵. 4.在网上找过很多博客,有的写得太多没耐心看,有的写得摘抄的定义,泛泛而谈,没有实操更没有讲解. 1.2 关于这篇分享对以上问题的解决 1.实践出真知,如果认真

架构设计:系统存储(8)——MySQL数据库性能优化(4)

================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的