大家帮忙分析mysql的死锁问题[根据下面的innodb status信息]

2019-03-25 13:37|来源: 网路

mysql> show innodb status;


------------------------

LATEST DETECTED DEADLOCK

------------------------

090220 10:22:45

*** (1) TRANSACTION:

TRANSACTION 0 16339728, ACTIVE 1 sec, process no 9502, OS thread id 1081506112 starting index read

mysql tables in use 1, locked 1

LOCK WAIT 24 lock struct(s), heap size 3024, 12 row lock(s), undo log entries 14

MySQL thread id 12261700, query id 169722445 192.168.10.11 nowbesixi_writer Updating

UPDATE cns_mail_log_2 SET cns_mail_log_2.mail_from_user_type=3 WHERE cns_mail_log_2.mail_id IN (32224) AND cns_mail_log_2.type = 1

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1525 page no 4 n bits 448 index `PRIMARY` of table `nowbesixi`.`cns_mail_log_2` trx id 0 16339728 lock_mode X waiting

Record lock, heap no 2 PHYSICAL RECORD: n_fields 10; compact format; info bits 0

0: len 3; hex 000001; asc    ;; 1: len 6; hex 000000608eb7; asc    `  ;; 2: len 7; hex 80000000320137; asc     2 7;; 3: len 1; hex 00; asc  ;; 4: len 4; hex 8000262b; asc   &+;; 5: len 4; hex 8000f957; asc    W;; 6: len 4; hex 80000002; asc     ;; 7: len 1; hex 80; asc  ;; 8: len 4; hex cb0b4d2b; asc   M+;; 9: len 1; hex 80; asc  ;;



*** (2) TRANSACTION:

TRANSACTION 0 16339725, ACTIVE 1 sec, process no 9502, OS thread id 1160436032 fetching rows, thread declared inside InnoDB 320

mysql tables in use 1, locked 1

1040 lock struct(s), heap size 145392, 384472 row lock(s), undo log entries 7

MySQL thread id 12262568, query id 169722418 192.168.10.12 nowbesixi_writer Updating

UPDATE cns_mail_log_2 SET cns_mail_log_2.mail_from_user_type=2 WHERE cns_mail_log_2.mail_id IN (32223) AND cns_mail_log_2.type = 1 AND cns_mail_log_2.mail_from_user_type = 1

*** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 1525 page no 4 n bits 448 index `PRIMARY` of table `nowbesixi`.`cns_mail_log_2` trx id 0 16339725 lock_mode X

Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

0: len 8; hex 73757072656d756d; asc supremum;;

相关问答

更多
  • 我不是这个专业的,但是目前在干这一行,刚入行不久。你的规划挺好的,挺有针对性。一方面你要考虑以后就业的兴趣,信息安全有技术层面也有管理层面,技术上又有两个主要的分支,一个以网络技术为主,一个以代码为主,两个分支都要涉及很多另一方的知识,而又各有专长,所以建议你在铺开专业面的前提下,选择自己感兴趣的方向深入学习。另一方面要学好英语,从我的经验来看,国内信息安全的主体构架还是国外的舶来品,自己的东西比较少,而且很多技术资料国内是没有中文版的,尽管网上可以下载,但是基本都是英文的,像兰德公司的风险评估方法报告,I ...
  • 这个不是mysql的进程。是你grep的进程,应该是没有了。 你看看mysql的服务启动项还有没有,如果没有的话,应该是卸掉了 chkconfig --list | grep mysqld
  • 试试这种方式: select account, status from tab where account in (select account from tab where status = 0) Sql小提琴演示 Try this way: select account, status from tab where account in (select account from tab ...
  • InnoDB插件将为您提供锁定和锁定查询的清晰画面。 例如 SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM informa ...
  • 将信息分解到特定页面是很困难的,尽管您可以从可能在PHP / Ruby / Python /等运行的脚本中检索并记录这些数据并记录下来。 对于更一般的Apache统计信息,您可以追加?auto以获得服务器状态的机器可读版本。 http://example.com/server-status?auto It would be difficult to break information down to a specific page, though you can retrieve and log that ...
  • 根本原因似乎是长期运行的应用程序事务。 解决方案是将大宗交易分解成更小的工作单元。 The root cause appears to have been long running application transactions. The solution was to break down the large transactions into smaller units of work.
  • 遗憾的是,无法清除SHOW ENGINE INNODB STATUS LATEST DETECTED DEADLOCK部分。 查询已被死锁检测器杀死,因此您无法KILL任何内容。 重置该信息的唯一方法是重新启动服务器。 由于该输出中存在某些东西,因此没有正确编写的软件应该持续发出警报。 There is no way to clear the LATEST DETECTED DEADLOCK section in SHOW ENGINE INNODB STATUS unfortunately. The qu ...
  • https://dba.stackexchange.com/q/87350 看看这个,你需要启用innodb_print_all_deadlocks https://dba.stackexchange.com/q/87350 Have a look at this, you need to enable innodb_print_all_deadlocks
  • 从MySQL 5.7开始,这将在performance_schema中进行检测。 请参见表performance_schema.status_by_thread http://dev.mysql.com/doc/refman/5.7/en/performance-schema-status-variable-tables.html Starting with MySQL 5.7, this is instrumented in the performance_schema. See table perfor ...
  • 这导致死锁,因为UPDATE查询锁定了表中的所有行,并且根据使用的索引(或缺少索引),两个不同的会话可能会以稍微不同的顺序锁定它们。 请记住, UPDATE , DELETE和SELECT ... FOR UPDATE将锁定它们遇到的所有行,无论这些行是否匹配所有WHERE条件。 因此,在使用它们时,您应该尽量通过使用索引(理想情况下是主键)并避免模糊或宽选条件来确保它们遇到尽可能少的行。 我对工作队列的建议非常普遍:尽可能少地锁定并始终以确定的顺序。 所以,一般来说: 使用非锁定读取(常规SELECT ) ...