webgame中Mysql Deadlock ERROR 1213 (40001)错误的排查历程

最新推荐文章于 2024-10-19 17:30:50 发布
最新推荐文章于 2024-10-19 17:30:50 发布
阅读量2k 收藏
点赞数
分类专栏： db


原文：https://www.2cto.com/database/201311/256554.html


案例发现:

从我们正在运营的一款webgame的异常日志中看到一些程序执行MYSQL 语句的报错信息。比较多的是“Deadlock found when trying to get lock; try restarting transaction”,少部分是“Error number: 1205:Lock wait timeout exceeded; try restarting transaction”，如下：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
001 --> 2012-11-22 06:05:36 --> ERROR   -->system/database/Driver.php--777--log--Debug
002 --> 2012-11-22 06:05:36 --> ERROR   -->system/database/Driver.php--295--error--JV_Driver
003 --> 2012-11-22 06:05:36 --> ERROR   -->system/database/ActiveRecord.php--947--query--JV_Driver
004 --> 2012-11-22 06:05:36 --> ERROR   -->server/models/MRoleMonster.php--84--update--JV_ActiveRecord
005 --> 2012-11-22 06:05:36 --> ERROR   -->server/daemon/update.php--392--kill--MRoleMonster
006 --> 2012-11-22 06:05:36 --> ERROR   -->   DATABASE: xxx_roles_xxx(10.1.1.75)
     -->  Error number: 1205:#####Lock wait timeout exceeded; try restarting transaction#####
     -->  Error Message: #####db_query_error --> Query Error: UPDATE `monster` SET `kills` = kills + 1 WHERE `id` = '30036' AND `role_id` = '19863'.#####
     -->  query elapsed counter: 184293;time 590.4272678
     -->  Database Connection has be closed:dbwRole
001 --> 2012-11-28 15:59:47 --> ERROR   -->system/database/Driver.php--777--log--Debug
002 --> 2012-11-28 15:59:47 --> ERROR   -->system/database/Driver.php--295--error--JV_Driver
003 --> 2012-11-28 15:59:47 --> ERROR   -->system/database/ActiveRecord.php--948--query--JV_Driver
004 --> 2012-11-28 15:59:47 --> ERROR   -->server/models/MRole.php--1143--update--JV_ActiveRecord
005 --> 2012-11-28 15:59:47 --> ERROR   -->server/daemon/update_other.php--283--updateRoleState--MRole
006 --> 2012-11-28 15:59:47 --> ERROR   -->   DATABASE: xxx_roles_xxx(10.1.1.72)
     -->  Error number: 1213:#####Deadlock found when trying to get lock; try restarting transaction#####
     -->  Error Message: #####db_query_error --> Query Error: UPDATE `role_state` SET `state` = 1
WHERE `role_id` = '53016' .#####
     -->  query elapsed counter: 4972;time 4.2417307
     -->  Database Connection has be closed:dbwRole
007 --> 2012-11-28 15:59:47 --> ERROR   -->system/database/Driver.php--616--log--Debug
008 --> 2012-11-28 15:59:47 --> ERROR   -->server/daemon/combat_update.php--308--transComplete--JV_Driver
009 --> 2012-11-28 15:59:47 --> ERROR   --> DB Transaction Failure.



 

从报错的英文上理解，大约是发生了“死锁”，以及“事务锁等待超时”两个错误异常。而且，都是我们后台PHP常驻进程遇到的问题。异常的代码对应行数上，大约可理解为执行SQL语句的一个指令，并无特殊的东西。有经验的程序员，很容易看出来，这不是程序的异常，这是MYSQL事务中，锁竞争的异常，客户端(PHP常驻进程)是没有语法上的错误的。那该如何排查呢？

一串疑问：
这是什么问题？如何排查？什么时候发生死锁？ 我怎么知道他发生了？ 发生之后去哪里排查？如何排查？怎么确定他们对应的事务中的所有SQL语句？ 分别在哪几个事务中？ 谁先锁的？谁后锁的？谁没锁到？谁报的死锁错误？ 死锁是什么？为什么发生了？ 如何避免？还有哪些因素影响？

毫无头绪:
程序间数据交互，上strace神器?
跟踪谁？ 客户端(php)？你知道哪个客户端会发生这个问题？你知道啥时候会发生？在你开始抓包到抓到死锁的期间，这得是多大的数据量？
跟踪谁？ 服务端(Mysql)？玩笑开大了吧？mysql以进程模式来处理客户端请求，每次都是一个新的进程，strace -ff参数的话，想想日志文件得被创建多少个，数据量会小么？
“万军之中取上将首级”这本事我可没…strace排查这种错误，还是算了吧。
这是谁报的错？显然是mysql，那就从根源找起–MYSQL server。

抓获现场:
我们要还原案发现场，有幸的时，我们有监控记录BINLOG以及SHOW ENGINE INNODB STATUS。到对应mysql服务器上，执行“show engine innodb status”获取INNODB引擎当前信息，大约如下：

 


?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
......
------------------------
LATEST DETECTED DEADLOCK
------------------------
121128 15:59:46
*** (1) TRANSACTION :
TRANSACTION AC512256, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 122562823, OS thread handle 0x7fa5c4fbe700, query id 7457663621 10.1.1.8 s001_gamedb Updating
UPDATE `role_state` SET `state` = 1
WHERE `role_id` = '53016'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 477 page no 1386 n bits 128 index ` PRIMARY ` of table `xxx_roles_xxx`.`role_state` trx id AC512256 lock_mode X locks rec but not gap waiting
Record lock, heap no 17 PHYSICAL RECORD: n_fields 80; compact format; info bits 0
  0: len 3; hex 00cf18; asc    ;;
......
......
*** (2) TRANSACTION :
TRANSACTION AC512250, ACTIVE 0 sec inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
6 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 2
MySQL thread id 122679850, OS thread handle 0x7fac007ff700, query id 7457663711 10.1.1.8 s001_gamedb update
REPLACE INTO `role_fight` (`role_id`, `life_max`, `mana_max`, `attack_physical`, `attack_internal`,****) VALUES ( '53016' , 4967, 3291, 350, 174, ***)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 477 page no 1386 n bits 128 index ` PRIMARY ` of table `xxx_roles_xxx`.`role_state` trx id AC512250 lock_mode X locks rec but not gap
Record lock, heap no 17 PHYSICAL RECORD: n_fields 80; compact format; info bits 0
......
......
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 427 page no 488 n bits 192 index ` PRIMARY ` of table `xxx_roles_xxx`.`role_fight` trx id AC512250 lock_mode X locks rec but not gap waiting
Record lock, heap no 64 PHYSICAL RECORD: n_fields 51; compact format; info bits 0
......
*** WE ROLL BACK TRANSACTION (1)
......

 

这是我精简之后的信息，我抓去了LATEST DETECTED DEADLOCK部分的数据，这部分的数据是INNODB的最后一次发生死锁的信息，更详细的说明见MYSQL官方手册对Standard Monitor and Lock Monitor Output返回结果的解释。
OK,发现一场案例，保存这个INNODB的状态数据备用。迅速到程序异常日志中查看相同时间点是否有死锁发生。果然，我们程序异常日志中记录了这起案例(文章开头的日志)。
再到binlog中抓去这个时间段前后10分钟(大约范围)的mysql sql语句执行日志。

案情分析：
engine status中，大约看出MYSQL记录了两个事务之间发生锁竞争时，遗留的数据，

事务1“执行”(注意，这里加了双引号)


UPDATE `role_state` SET `state` = 1 WHERE `role_id` = '53016'
发现被修改资源已经被lock_mode X locks了(详情见: INNODB锁模式)，准备等待该资源锁被释放

事务2执行

 

REPLACE INTO `role_fight` (`role_id`, `life_max`, `mana_max`, `attack_physical`, `attack_internal`,****) VALUES ('53016', 4967, 3291, 350, 174, ***)

 

也发现该资源被lock_mode X locks了。

最后部分，mysql给了很重要的一个数据“WE ROLL BACK TRANSACTION (1)” MYSQL回滚了事物1。既然mysql回滚了1，那么肯定是事务1的语句触发了死锁，被mysql回滚了，也就是应该为程序中的异常日志所记录的那部分。同时，MYSQL执行了事务2，那么事务2的SQL语句肯定被记录在BINLOG中了。

抽丝剥茧:
如何确定事务1、事务2执行了哪些SQL语句呢？
根据show engine innodb status的结果，确定事务2被执行的

  • SQL语句(业务逻辑的role_id唯一标识): REPLACE INTO `role_fight` (`role_id`, `life_max`, `mana_max`, `attack_physical`, `attack_internal`,****) VALUES (’53016′, 4967, 3291, 350, 174, ***)
  • 线程ID(mysql的唯一标识): MySQL thread id 122679850
  • 执行时间(时间线):121128 15:59:46

根据这三个标识，以及BINLOG的起始表示“BEGIN、COMMIT”，几乎可以100%确定该事务所包含的SQL语句。

BINLOG信息大约如下:



?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# at 511750764
#121128 15:59:46 server id 1  end_log_pos 511750843     Query   thread_id=122679850 exec_time=0 error_code=0
SET TIMESTAMP =1354089586 /*!*/ ;
BEGIN
/*!*/ ;
# at 511750843
#121128 15:59:46 server id 1  end_log_pos 511751090     Query   thread_id=122679850 exec_time=0 error_code=0
use xxx_roles_xxx /*!*/ ;
SET TIMESTAMP =1354089586 /*!*/ ;
UPDATE `role_pet` SET `in_supporting` = 0, `levelup_pause_time` = 1354089587, `auto_feed` = 0, `supporting_pause_time` = 1354089587
WHERE `role_id` = '53016'
AND `id` = 9234
/*!*/ ;
# at 511751090
#121128 15:59:46 server id 1  end_log_pos 511751240     Query   thread_id=122679850 exec_time=0 error_code=0
SET TIMESTAMP =1354089586 /*!*/ ;
UPDATE `role_state` SET `pet` = 0, `pet_level` = 0
WHERE `role_id` = '53016'
/*!*/ ;
# at 511751240
#121128 15:59:46 server id 1  end_log_pos 511751885     Query   thread_id=122679850 exec_time=0 error_code=0
SET TIMESTAMP =1354089586 /*!*/ ;
REPLACE INTO `role_fight` (`role_id`, `life_max`, `mana_max`, `attack_physical`, `attack_internal`, `defend_physical`, `defend_internal`, `dodge_rate`, `critical_rate`, `hit_rate`, `speed`, `defend_physical_plus`, `defend_internal_plus`, `dodge_level`,*****) VALUES ( '53016' , 4967, 3291, 350, 174, 518, 254, 500, 300, 9500, 913, 668, 668, 261, 700, 97, 133, 40.9, 34, *****)
/*!*/ ;
# at 511751885
#121128 15:59:46 server id 1  end_log_pos 511751912     Xid = 7457663579
COMMIT /*!*/ ;

 

OK,事务2的SQL语句全部找齐了。那么事务1的呢？如何找？

根据php的异常报错，确定主要包含的语句SQL信息，以及程序跟踪的代码行数，根据代码逻辑去确定该事务的所有SQL语句。再去BINLOG中找到该用户的该业务的类似BINLOG：



?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# at 511805324
#121128 15:59:53 server id 1  end_log_pos 511805403     Query   thread_id=122562823 exec_time=0 error_code=0
SET TIMESTAMP =1354089593 /*!*/ ;
BEGIN
/*!*/ ;
# at 511805403
#121128 15:59:53 server id 1  end_log_pos 511805560     Query   thread_id=122562823 exec_time=0 error_code=0
use xxx_roles_xxx /*!*/ ;
SET TIMESTAMP =1354089593 /*!*/ ;
UPDATE `role_fight` SET `last_update_life` = '1354089587'
WHERE `role_id` = '53016'
/*!*/ ;
# at 511805560
#121128 15:59:53 server id 1  end_log_pos 511805695     Query   thread_id=122562823 exec_time=0 error_code=0
SET TIMESTAMP =1354089593 /*!*/ ;
UPDATE `role_state` SET `state` = 1
WHERE `role_id` = '53016'
/*!*/ ;
# at 511805695
#121128 15:59:53 server id 1  end_log_pos 511805889     Query   thread_id=122562823 exec_time=0 error_code=0
use xxx_roles_xxx /*!*/ ;
SET TIMESTAMP =1354089593 /*!*/ ;
DELETE FROM `queue_combats_update_roles`
WHERE `combat_id` = 'f27d62dad8efcaeb04cd8f5d7c0424db'
AND `role_id` = '53016'
/*!*/ ;
# at 511805889
#121128 15:59:53 server id 1  end_log_pos 511805916     Xid = 7457670215
COMMIT /*!*/ ;

(请勿过于纠结上面binlog的thread_id跟show engine innodb status的thread_id一致的问题，这是因为我们程序是常驻进程，mysql连接不断开，不销毁，故一致了。而且，此日志是程序发现死锁之后，被mysql回滚之后，又重新提交的事务，算是不同时间点的相同事务)

案情还原：
根据案发现场的两个MYSQL INNODB事务的全部SQL语句，以及形成MYSQL INNODB 死锁的原因(感谢DBA组大雄哥的纠正)，我们大约可以这么还原案情:

事务1：
UPDATE `role_fight` SET `last_update_life` = ’1354089587′ WHERE `role_id` = ’53016′
UPDATE `role_state` SET `state` = 1 WHERE `role_id` = ’53016′

事务2：
UPDATE `role_state` SET `pet` = 0, `pet_level` = 0 WHERE `role_id` = ’53016′
REPLACE INTO `role_fight` (`role_id`, `life_max`, `mana_max`, `attack_physical`, `attack_internal`,****) VALUES (’53016′, 4967, 3291, 350, 174, ***)

这四条语句构成了本次事务死锁的全部原因。
执行顺序肯定如下:

时间点事务1事务2备注
1begin  
2 begin 
3 UPDATE `role_state` SET `pet` = 0, `pet_level` = 0 WHERE `role_id` = ’53016′事务2 给 role_state表 role_id 53016记录上 X 锁
4UPDATE `role_fight` SET `last_update_life` = ’1354089587′ WHERE `role_id` = ’53016′ 事务1 给 role_fight表 role_id 53016记录上 X 锁
5 REPLACE INTO `role_fight` (`role_id`, `life_max`, `mana_max`, `attack_physical`, `attack_internal`,****) VALUES (’53016′, 4967, 3291, 350, 174, ***)这里是重点，事务2给role_fight表role_id的记录上 X 锁，发现被其他人(事务1)上锁了，开始等待他人提交事务…等待…
6UPDATE `role_state` SET `state` = 1 WHERE `role_id` = ’53016′ 事物1打算给role_state表role_id为53016记录上 X 排它锁，发现被其他事务上了，而且此事务居然还在等他提交，这时MYSQL立刻回滚事务1…(php发现MYSQL返回死锁信息，随记录该信息到异常日志…发送回滚指令…mysql已经“帮”他回滚了…)
7 【执行成功…】事务2发现别人释放锁了，OK，获取X锁，修改成功
8 commitPHP程序发现上一条指令执行完毕，且执行无错，即，发送commit指令，提交事务。

好像有个参数%^&#:
innodb_lock_wait_timeout参数是干啥的呢？从mysql官方手册上看，此参数是针对锁等待时，一个限定等待时间的参数。跟死锁并无关系，一旦mysql发现死锁，立刻回滚导致死锁的语句。并不会用到该参数。

规避方式：

  • 缩小事务的语句数量
  • 调整SQL语句执行顺序，变“死锁”为“锁等待”，等待一会，总比整个事务回滚掉，全部重新再执行这个流程要强.
  • 其他.请补充

关于锁等待:
缩小事务间SQL语句的数量，减小规模吧。当然，提高检索速度，提高查询时间也是首要因素，我们就发现我们的SQL语句中，有几个没有用到索引，导致锁表，导致锁等待发生…


还不够
关注
专栏目录
mysql错误码 1213_webgame中Mysql Deadlock ERROR 1213 (40001)错误的排查历程_MySQL
weixin_30369779的博客
01-18 1876
bitsCN.com案例发现:从我们正在运营的一款webgame的异常日志中看到一些程序执行MYSQL 语句的报错信息。比较多的是“Deadlock found when trying to get lock; try restarting transaction”,少部分是“Error number: 1205:Lock wait timeout exceeded; try restarting...
mysql error 1213_删除数据引发ERROR 1213 (40001) at line 7: Deadlock found when trying
weixin_42328834的博客
01-19 1555
MySQL存储过程 ERROR Handler 异常处理问题样例：当insert失败时，我希望将其记录在日志文件中，》》在这里需要创建一个主键表，以及一个外键表，我们使用的是Innodb ，因此外键关联检查是打开的，当我向外键表中插入非主键表中的值时，动作将会失败，创建的数据表如下：create table t2(s1 int primary key)engine=innodb;//create ...
【mysql】并发 Insert 的死锁问题：Deadlock found when trying to get lock； try restarting transaction
lixiaonan0318的博客
08-14 576
这样可以控制多个事务锁定资源的顺序，也就是在一个事务中，执行子查询会锁定 pid 所在的行（X锁），直至 Insert 结束，此过程中其他事务不能在对相同行加 X锁或S锁，需等待前一个事务完成后才能继续执行。`，导致事务在计算 display_order 值的过程中，锁定相关行。如果多个事务同时执行插入操作，锁定相同的行，就会导致互相等待的情况，出现死锁。但是不能完全解决问题，当多个并发事务语句中的 pid 相同时，仍会锁定相同行，导致死锁。：使用事务，先执行子查询，获取数据后在同一个事务中执行插入。
mysql error 1213_mysql innodb行锁解锁后出现1213死表现象Deadlock found when解_MySQL
weixin_39840153的博客
02-26 683
bitsCN.commysql innodb行锁解锁后出现1213死表现象Deadlock found when解决出现这个原因要记住一点就是：innodb的行锁 和解锁都是针对主键索引的。如果查询时根据索引锁表，但更新时却不是通过主键更新，那么等待的解锁查询的进程将会报1213错误，程序里有可能返回一个null值实例：tablesoldgoods (表名)soldgoodsID 索引produc...
mysql错误码 1213_mysql error 1201-1300错误分析
weixin_39672296的博客
01-18 1938
·错误：1201SQLSTATE: HY000 (ER_MASTER_INFO)消息：无法初始化主服务器信息结构，在MySQL错误日志中可找到更多错误消息。·错误：1202SQLSTATE: HY000 (ER_SLAVE_THREAD)消息：无法创建从线程，请检查系统资源。·错误：1203SQLSTATE: 42000 (ER_TOO_MANY_USER_CONNECTIONS)消息：用户...
mysql delete出现1213_删除数据引发ERROR 1213 (40001) at line 7: Deadlock found when trying
weixin_39769406的博客
01-19 555
MySQL存储过程 ERROR Handler 异常处理问题样例：当insert失败时，我希望将其记录在日志文件中，》》在这里需要创建一个主键表，以及一个外键表，我们使用的是Innodb ，因此外键关联检查是打开的，当我向外键表中插入非主键表中的值时，动作将会失败，创建的数据表如下：create table t2(s1 int primary key)engine=innodb;//create ...
mysql error 1213_webgame中Mysql Deadlock ERROR 1213 (40001)错误的排查历程
06-10
MySQL Deadlock ERROR 1213 (40001)是一个常见的错误，通常发生在高并发的情况下。...综上所述，排查MySQL Deadlock ERROR 1213 (40001)错误需要综合考虑多方面的因素，并采取相应的措施来解决问题。
webgame网页游戏开发设计简明教程中文WORD版
07-22
资源名称：webgame网页游戏开发设计简明教程 中文WORD版本文档是webgame网页游戏开发设计简明教程；webgame程序构成：三大部分。第一是数据流程。第二是程序。第三是美术。其中，数据流程包括了功能。也只有在功能中...
WebGame
03-15
WebGame是一种基于网络的互动游戏形式，它将玩家带入了一个可以实时交互的虚拟世界。在WebGame领域，开发语言Swift并非传统首选，因为通常Web游戏更多地使用JavaScript、HTML5和CSS3进行开发，但这并不意味着Swift不...
Webgame自动化测试之游戏测试方法
03-23
与之前的web2.0的互联网应用相比，webgame的测试更多样，也更加的复杂 　最近两个项目中游荡，首次接触facebook游戏的测试，感触还是很多的。与之前的web2.0的互联网应用相比，webgame的测试更多样，也更加的复杂。...
科普文：软件架构数据库系列之【MySQL死锁案例分析：加锁顺序“循环等待”导致的死锁及解决方案 ERROR 1213 (40001): Deadlock】
最新发布
为无为，事无事，味无味。
10-19 953
前面index_merge导致的死锁，是MySQL优化器的内部行为，可能不是很好理解。在这里我们按照产生死锁的四个必要条件，来模拟死锁。及加锁形成了“循环等待”最终导致死锁。死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。
MySQL错误整理
HuY的博客
09-04 803
1. ERROR 1213(40001)ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transactionmysql出现了锁死问题，操作修改数据库表时出现报错，说明还有程序占用着数据库表，无法修改。可以查看下编译器是不是还在调试、占用着数据库表。2. Field ‘id’ doesn’t hav
mysql select 40001_MySQL 死锁产生原因及解决方法
weixin_42366200的博客
02-01 1416
一、Mysql 锁类型和加锁分析1、锁类型介绍：MySQL有三种锁的级别：页级、表级、行级。表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般算法：next KeyLocks锁，同时锁住记...
mysql死锁分析
那片天空！那片海！
04-11 4410
在性能测试过程中，时常会遇到这样的问题：SQLSTATE[40001]: Serialization failure: 1213 Deadlock found whentrying to get lock; try restarting transaction 首先我们执行 show engine innodb status\G;查看死锁情况，也可以mysql -u root -p --
mysql报ERROR：Deadlock found when trying to get lock; try restarting transaction（nodejs）
weixin_30594001的博客
07-11 1241
1前言 出现错误 Deadlock found when trying to get lock; try restarting transaction。然后通过网上查找资料，重要看到有用信息了。 错误图片如下： 2解决方案 由于mysql执行delete操作时WHERE中字段使用了非主键，然而那个表有在进行其它操作时，就会出现这个错了。所以只要删除时使用主键作为条件即可...
mysql死锁 DeadLock定位与解决
热门推荐
进化的深山猿
01-24 2万+
mysql死锁问题定位与解决 java后台报错如下 java.util.concurrent.ExecutionException: org.springframework.dao.DeadlockLoserDataAccessException: ### Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQ...
mysql1213错误表锁死 mysql 1213 deadlock found when trying to get lock try restarting transaction
D.調の華麗
04-15 4870
错误：mysql 1213 deadlock found when trying to get lock try restarting transaction 1.检查被占用的表： show OPEN TABLES where In_use > 0; 2.显示进程： show processlist; 3.杀死挂起的进程即导致表锁死的进程： kill 17909;---17909是进程的id ...
mysql innodb 行锁解锁后出现1213 死表现象 Deadlock found when
【CSDN】
07-25 1629
[Err] 1213 - Deadlock found when trying to get lock; try restarting transaction 出现这个原因要记住一点就是：innodb的行锁 和解锁都是针对主键索引的。如果查询时根据索引锁表，但更新时却不是通过主键更新，那么等待的解锁查询的进程将会报1213错误，程序里有可能返回一个null值 实例： tabl...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值