4

このような単純な削除クエリはどのようにして MySQL でデッドロックを引き起こすのでしょうか?具体的にはどうすればよいでしょうか?

DELETE FROM view_offers WHERE view_id = 55

テーブル用

CREATE TABLE `view_offers` (
  `view_id` int(11) NOT NULL DEFAULT '0',
  `user_id` int(11) DEFAULT NULL,
  `offer_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `offer_source` int(11) NOT NULL,
  `offer_source_id` bigint(20) unsigned NOT NULL,
  `product_id` bigint(20) unsigned DEFAULT NULL,
  `shop_id` bigint(20) unsigned DEFAULT NULL,
  `category_id` mediumint(8) unsigned DEFAULT NULL,
  `name` varchar(255) DEFAULT NULL,
  `relevance` float NOT NULL DEFAULT '0',
  PRIMARY KEY (`view_id`,`offer_id`),
  KEY `index_view_offers_on_view_id_and_product_id` (`view_id`,`product_id`),
  KEY `index_view_offers_on_view_id_and_shop_id` (`view_id`,`shop_id`),
  KEY `index_view_offers_on_view_id_and_category_id` (`view_id`,`category_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

私は、プログラミングのコンテキストにおけるデッドロック自体の概念を認識しています。複数のテーブルを異なる順序で同時にロックすると、データベースでデッドロックが発生することは理解できますが、このクエリにはテーブルが 1 つしかありません...

これは、テーブル レベルではなくキー レベルで発生していますか? 私の Rails アプリには、100 とまではいかなくても、数十の異なるクエリが必要です。

デッドロックに関係する他のクエリを見つけるにはどうすればよいですか?

編集:これはデッドロック情報ですSHOW InnoDB STATUS

私がこれを理解する限り: - スレッド 1 にはロックがなく、PRIMARY のロックを待機します - スレッド 2 には PRIMARY のロックがあり、PRIMARY のロックを待機します これは、デッドロックのように聞こえないため、私には意味がありません。

------------------------
LATEST DETECTED DEADLOCK
------------------------
130214 18:06:52
*** (1) TRANSACTION:
TRANSACTION 0 6720854, ACTIVE 2 sec, process no 10951, OS thread id 140317946369792 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1216, 1 row lock(s)
MySQL thread id 419387, query id 2333457 10.0.3.3 foo updating
DELETE FROM view_offers WHERE view_id = 55
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 6987532 n bits 168 index `PRIMARY` of table `foo`.`view_offers` trx id 0 6720854 lock_mode X waiting
Record lock, heap no 41 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 0: len 4; hex 80000037; asc    7;; 1: len 8; hex 00005f9c7d5f9261; asc   _ }_ a;; 2: len 6; hex 000000668d4c; asc    f L;; 3: len 7; hex 80001ec007080d; asc        ;; 4: len 4; hex 80000039; asc    9;; 5: len 4; hex 80000002; asc     ;; 6: len 8; hex 000000000c001798; asc         ;; 7: len 8; hex 022c4f4dc34a1e6e; asc  ,OM J n;; 8: len 8; hex 02796b4da8fe914c; asc  ykM   L;; 9: len 3; hex 019342; asc   B;; 10: len 30; hex 4e722e2035382050686f746f202831376d6c29202d2054696e74656e6661; asc Nr. 58 Photo (17ml) - Tintenfa;...(truncated); 11: len 4; hex 00000000; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 0 6720844, ACTIVE 3 sec, process no 10951, OS thread id 140336508557056 inserting, thread declared inside InnoDB 500
mysql tables in use 2, locked 2
7762 lock struct(s), heap size 817136, 82058 row lock(s), undo log entries 28808
MySQL thread id 419384, query id 2333448 10.0.3.2 foo Sending data
INSERT INTO view_offers SELECT 55, 57, uiid, source, source_id, 100, 200, category_id, name, relevance FROM `offers`  WHERE `offers`.`source` IN (2) AND (((product_source = 2 AND product_source_id IN (1,2,3,..
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 6987532 n bits 152 index `PRIMARY` of table `foo`.`view_offers` trx id 0 6720844 lock_mode X locks rec but not gap
Record lock, heap no 41 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 0: len 4; hex 80000037; asc    7;; 1: len 8; hex 00005f9c7d5f9261; asc   _ }_ a;; 2: len 6; hex 000000668d4c; asc    f L;; 3: len 7; hex 80001ec007080d; asc        ;; 4: len 4; hex 80000039; asc    9;; 5: len 4; hex 80000002; asc     ;; 6: len 8; hex 000000000c001798; asc         ;; 7: len 8; hex 022c4f4dc34a1e6e; asc  ,OM J n;; 8: len 8; hex 02796b4da8fe914c; asc  ykM   L;; 9: len 3; hex 019342; asc   B;; 10: len 30; hex 4e722e2035382050686f746f202831376d6c29202d2054696e74656e6661; asc Nr. 58 Photo (17ml) - Tintenfa;...(truncated); 11: len 4; hex 00000000; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 6987532 n bits 184 index `PRIMARY` of table `foo`.`view_offers` trx id 0 6720844 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 41 PHYSICAL RECORD: n_fields 12; compact format; info bits 0
 0: len 4; hex 80000037; asc    7;; 1: len 8; hex 00005f9c7d5f9261; asc   _ }_ a;; 2: len 6; hex 000000668d4c; asc    f L;; 3: len 7; hex 80001ec007080d; asc        ;; 4: len 4; hex 80000039; asc    9;; 5: len 4; hex 80000002; asc     ;; 6: len 8; hex 000000000c001798; asc         ;; 7: len 8; hex 022c4f4dc34a1e6e; asc  ,OM J n;; 8: len 8; hex 02796b4da8fe914c; asc  ykM   L;; 9: len 3; hex 019342; asc   B;; 10: len 30; hex 4e722e2035382050686f746f202831376d6c29202d2054696e74656e6661; asc Nr. 58 Photo (17ml) - Tintenfa;...(truncated); 11: len 4; hex 00000000; asc     ;;

*** WE ROLL BACK TRANSACTION (1)
4

0 に答える 0