-
奇怪的mysql死锁，当有外键索引的时候，会需要请求对关联表的锁吗？20
请教数据库死锁问题，现象是在回复帖子的时候出现死锁
以下是mysql show innodb status结果：
InnoDB | |
=====================================
120611 11:14:34 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 36 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 20196, signal count 20099
Mutex spin waits 0, rounds 608422, OS waits 1472
RW-shared spins 37967, OS waits 18286; RW-excl spins 4688, OS waits 290
------------------------
LATEST DETECTED DEADLOCK
------------------------
120608 10:53:29
*** (1) TRANSACTION:
TRANSACTION 0 3055951996, ACTIVE 38 sec, OS thread id 11112 inserting
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 320, 2 row lock(s), undo log entries 2
MySQL thread id 823, query id 9503198 localhost 127.0.0.1 root update
insert into housesociety.housesubject_discuss (house_subject_id, user_id, isaviabled, content, istop, createtime) values (2356, 17841, 1, '没退学去创业！！', 0, '2012-06-08 10:52:58')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 1318267 n bits 136 index `PRIMARY` of table `housesociety`.`users` trx id 0 3055951996 lock mode S locks rec but not gap waiting
Record lock, heap no 26 PHYSICAL RECORD: n_fields 33; compact format; info bits 0
0: len 4; hex 800045b1; asc E ;; 1: len 6; hex 0000b626206b; asc & k;; 2: len 7; hex 000000c0c10626; asc &;; 3: len 0; hex ; asc ;; 4: len 6; hex e58d83e5b886; asc ;; 5: len 30; hex 653130616463333934396261353961626265353665303537663230663838; asc e10adc3949ba59abbe56e057f20f88;...(truncated); 6: SQL NULL; 7: len 1; hex 00; asc ;; 8: len 30; hex 557365722f5573657248656164496d6167652f31373834312f736d616c6c; asc User/UserHeadImage/17841/small;...(truncated); 9: len 30; hex 557365722f5573657248656164496d6167652f31373834312f3230313131; asc User/UserHeadImage/17841/20111;...(truncated); 10: SQL NULL; 11: SQL NULL; 12: len 20; hex 7169616e66616e407961686f6f2e636f6d2e636e; asc qianfan@yahoo.com.cn;; 13: len 4; hex 80000060; asc `;; 14: len 4; hex 80000060; asc `;; 15: len 4; hex 80000000; asc ;; 16: len 0; hex ; asc ;; 17: len 0; hex ; asc ;; 18: SQL NULL; 19: len 4; hex 80000000; asc ;; 20: len 8; hex 8000124a81e4e928; asc J (;; 21: len 4; hex 80000000; asc ;; 22: len 4; hex 80000000; asc ;; 23: len 4; hex 80000003; asc ;; 24: len 4; hex 80000000; asc ;; 25: SQL NULL; 26: len 1; hex 01; asc ;; 27: len 4; hex 80000000; asc ;; 28: SQL NULL; 29: SQL NULL; 30: len 8; hex 8000124a8231cd27; asc J 1 ';; 31: len 8; hex 696e7465726e616c; asc internal;; 32: len 8; hex 8000124cb1b2e308; asc L ;;
*** (2) TRANSACTION:
TRANSACTION 0 3055951979, ACTIVE 65 sec, OS thread id 15184 starting index read, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
4 lock struct(s), heap size 320, 2 row lock(s), undo log entries 1
MySQL thread id 803, query id 9503531 localhost 127.0.0.1 root Updating
update housesociety.house_subjects set click_count=click_count+1 where id=2356
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 1318267 n bits 136 index `PRIMARY` of table `housesociety`.`users` trx id 0 3055951979 lock_mode X locks rec but not gap
Record lock, heap no 26 PHYSICAL RECORD: n_fields 33; compact format; info bits 0
0: len 4; hex 800045b1; asc E ;; 1: len 6; hex 0000b626206b; asc & k;; 2: len 7; hex 000000c0c10626; asc &;; 3: len 0; hex ; asc ;; 4: len 6; hex e58d83e5b886; asc ;; 5: len 30; hex 653130616463333934396261353961626265353665303537663230663838; asc e10adc3949ba59abbe56e057f20f88;...(truncated); 6: SQL NULL; 7: len 1; hex 00; asc ;; 8: len 30; hex 557365722f5573657248656164496d6167652f31373834312f736d616c6c; asc User/UserHeadImage/17841/small;...(truncated); 9: len 30; hex 557365722f5573657248656164496d6167652f31373834312f3230313131; asc User/UserHeadImage/17841/20111;...(truncated); 10: SQL NULL; 11: SQL NULL; 12: len 20; hex 7169616e66616e407961686f6f2e636f6d2e636e; asc qianfan@yahoo.com.cn;; 13: len 4; hex 80000060; asc `;; 14: len 4; hex 80000060; asc `;; 15: len 4; hex 80000000; asc ;; 16: len 0; hex ; asc ;; 17: len 0; hex ; asc ;; 18: SQL NULL; 19: len 4; hex 80000000; asc ;; 20: len 8; hex 8000124a81e4e928; asc J (;; 21: len 4; hex 80000000; asc ;; 22: len 4; hex 80000000; asc ;; 23: len 4; hex 80000003; asc ;; 24: len 4; hex 80000000; asc ;; 25: SQL NULL; 26: len 1; hex 01; asc ;; 27: len 4; hex 80000000; asc ;; 28: SQL NULL; 29: SQL NULL; 30: len 8; hex 8000124a8231cd27; asc J 1 ';; 31: len 8; hex 696e7465726e616c; asc internal;; 32: len 8; hex 8000124cb1b2e308; asc L ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 1612378 n bits 80 index `PRIMARY` of table `housesociety`.`house_subjects` trx id 0 3055951979 lock_mode X locks rec but not gap waiting
Record lock, heap no 8 PHYSICAL RECORD: n_fields 19; compact format; info bits 0
0: len 4; hex 80000934; asc 4;; 1: len 6; hex 0000b626207c; asc & |;; 2: len 7; hex 000000c0c3039b; asc ;; 3: len 4; hex 80000128; asc (;; 4: len 4; hex 8000492d; asc I-;; 5: len 30; hex e38090e6b4bbe58aa8e5be81e99b86e38091e58f88e698afe4b880e5b9b4; asc ;...(truncated); 6: len 30; hex 3c70207374796c653d22746578742d616c69676e3a206c6566743b223e3c; asc <p style="text-align: left;"><;...(truncated); 7: len 1; hex 01; asc ;; 8: len 4; hex 80000000; asc ;; 9: len 8; hex 8000124cb1b2dc19; asc L ;; 10: len 4; hex 80000003; asc ;; 11: len 1; hex 00; asc ;; 12: len 4; hex 80000000; asc ;; 13: len 1; hex 00; asc ;; 14: len 4; hex 80000008; asc ;; 15: len 8; hex 8000124cb1b2e32a; asc L *;; 16: len 1; hex 01; asc ;; 17: len 30; hex 31383733332f32303132303630383130323230335f31383733332e6a7067; asc 18733/20120608102203_18733.jpg;; 18: len 30; hex e38090e6b4bbe58aa8e5be81e99b86e38091e6af95e4b89ae982a3e4ba9b; asc ;...(truncated);
*** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
------------
感觉很奇怪，在插入和更新的操作中，会需要请求对关联表的锁吗？
（上面的日志貌似说：插入 和更新的时候都需要请求锁住 users表？）
问题补充：该问题是在hibernate中遇到的。2012年6月11日 14:03
添加评论
关注(0)
目前还没有答案
相关推荐
在MySQL中，外键用于维护表之间的引用完整性，如果没有索引，进行关联操作时可能会导致大量的全表扫描，增加锁定的机会，从而引发死锁。第二大原因是并发修改位图索引，这在多用户并发访问时尤其常见，如果两个事务...
7. **死锁或事务冲突**：在并发环境中，如果两个事务同时尝试对同一组表进行操作，可能会导致死锁，从而引发1005错误。在这种情况下，需要检查并解决并发控制问题，或者重新尝试操作。 8. **权限问题**：如果没有...
支持表级锁，即每次操作是对整个表加锁； 存储表的总行数； 一个MYISAM表有三个文件：索引文件、表结构文件、数据文件； 采用非聚集索引，索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致，但是...
### MySQL数据库面试宝典...这些知识点涵盖了MySQL数据库的基础知识、数据类型、存储引擎、索引、事务、锁、视图、存储过程与函数等方面的核心概念和技术细节，对于准备MySQL面试的候选人来说是非常有价值的参考资料。
数据库锁用于并发控制，常见的锁类型有读锁（共享锁）和写锁（排他锁），还有行级锁、页级锁和表级锁等，适用于不同级别的并发场景。 数据库复制是实现高可用性和故障恢复的重要手段，主从复制允许数据从主服务器...
MySQL 中有多种锁，包括表级锁、行级锁、页面锁： 1. 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 2. 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突...
6.2.1是否向服务器请求了不需要的数据196 6.2.2MySQL是否在扫描额外的记录198 6.3重构查询的方式201 6.3.1一个复杂查询还是多个简单查询201 6.3.2切分查询202 6.3.3分解关联查询203 6.4查询执行的基础204 ...
### MySQL存储引擎索引分析主从配置监控实战教程，锁分析，碎片管理，权限管理 #### MySQL简介 MySQL是一款广泛使用的开源关系型数据库管理系统。它以其高性能、可靠性和易用性而闻名，适用于多种应用场景，从简单...
本节总结了 MySQL 相关的知识点，包括索引的使用注意事项、索引的优化、死锁问题的解决、SQL 优化、分库分表的设计、InnoDB 与 MyISAM 的区别、数据库索引的原理等。 索引的使用注意事项 在使用 MySQL 索引时，...
在深入探讨mysql中explain语句的使用和解释之前，有必要先介绍mysql的存储引擎，因为不同的存储引擎对于数据库性能有着直接的影响。 存储引擎是mysql中用于存储、检索和索引数据的组件。不同的存储引擎具有各自的...
MySQL 中有三种锁：表级锁、行级锁、页面锁。表级锁开销小，加锁快，不会出现死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低。行级锁开销大，加锁慢，会出现死锁，锁定粒度最小，发生锁冲突的概率最低，并发度...
面试中，MySQL相关的知识点是必考题目，本文将从 MySQL 的基本概念、索引、锁机制、事务、存储引擎、优化等方面对MySQL面试题进行详解。 索引相关知识点 索引是数据库中的一个重要概念，它可以提高查询速度、减少...
1. MySQL 中有三种锁机制：表级锁、行级锁、页面锁。表级锁开销小，加锁快，不会出现死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低。行级锁开销大，加锁慢，会出现死锁，锁定粒度最小，发生锁冲突的概率最低...
标题《MYSQL必会必知》指出了本文的重点在于介绍MySQL数据库的基础知识，强调了学习MySQL的必要性。描述部分重复强调了“mysql基础”，可能是由于文档错误，不过这仍然突出了本文的主旨：掌握MySQL的基础操作和概念...
- MySQL 估计使用全表扫描要比使用索引快，則不使用索引 2. 索引不适合哪些场景： - 数据量少的不适合加索引 - 更新比较频繁的也不适合加索引 - 区分度低的字段不适合加索引（如性别） 3. 索引的一些潜规则： ...
在深入分析MySQL加锁处理之前，首先需要了解MySQL数据库的基本架构以及锁机制的相关概念。MySQL是一个支持插件式存储引擎的数据库系统，其中InnoDB存储引擎因其支持事务处理和外键约束而被广泛使用。本文将重点讨论...
MySQL 中有三种锁：表级锁、行级锁、页面锁。表级锁开销小，加锁快，不会出现死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低。行级锁开销大，加锁慢，会出现死锁，锁定粒度最小，发生锁冲突的概率最低，并发度...