これらの2つのクエリでデッドロックが発生するのはなぜですか？

Question

隔離レベルはREAD COMMITTED

1つのクエリは、service_idが0のレコードを探しています。もう1つは、service_idがIN（0、... others ...）ではない場所を探しています。

私は彼らが異なる行をロックすると思いますか？

------------------------ 
    LATEST DETECTED DEADLOCK 
    ------------------------ 
    2017-08-18 09:01:24 7f2d05641700 
    *** (1) TRANSACTION: 
    TRANSACTION 201694975, ACTIVE 1 sec starting index read 
    mysql tables in use 2, locked 2 
    LOCK WAIT 46 lock struct(s), heap size 6544, 194 row lock(s) 
    MySQL thread id 33600289, OS thread handle 0x7f2d0812b700, query id 3703173090 inf-rtpctllb02-prd.rtp.netapp.com 10.60.56.150 ctl Copying to tmp table 
    SELECT 
         re.*, 
         r.config_id, 
         r.reserve_all_or_nothing, 
         r.owner, 
         r.charges 
        FROM 
         `job_charge` AS re, 
         `job` AS r WHERE 
         re.job_id = r.id AND ((re.status ='dispatched') or (re.status= 'running') or (re.status= 'held') or (re.status= 'reserved')) AND ((re.service_id ='0')) AND r.disable = 0 ORDER BY r.priority,r.id LIMIT 10000 FOR UPDATE 
    *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
    RECORD LOCKS space id 1485 page no 987 n bits 104 index `PRIMARY` of table `ctl`.`job_charge` trx table locks 2 total table locks 2 trx id 201694975 lock_mode X locks rec but not gap waiting lock hold time 1 wait time before grant 0 
    *** (2) TRANSACTION: 
    TRANSACTION 201691925, ACTIVE 185 sec fetching rows 
    mysql tables in use 4, locked 2 
    1164 lock struct(s), heap size 128552, 2 row lock(s) 
    MySQL thread id 33599597, OS thread handle 0x7f2d05641700, query id 3703158120 inf-rtpctllb02-prd.rtp.netapp.com 10.60.56.150 ctl updating 
    UPDATE 
       `job_charge` 
      SET 
       service_id = '0' 
      WHERE 
       service_id NOT IN ('0','ctl5-staging_command-launcher.674d8c96-7c76-11e7-bc6c-ee0cf095fd00','inf-mesos-slave001.ctl.gdl.englab.netapp.com:mesos-6b256982-4ef1-4a84-ba60-58245ee7406d-S63.3987fd54-ee31-4c81-add4-4be53a6ed363:80','ctl5-staging_scheduler.912d008f-7c76-11e7-bc6c-ee0cf095fd00','ctl5-production_capacity-manager.6a869ee7-7919-11e7-bc6c-ee0cf095fd00','ctl5-production_scheduler.91de7d76-7919-11e7-bc6c-ee0cf095fd00','mysql','inf-mesos-slave001.ctl.gdl.englab.netapp.com:mesos-6b256982-4ef1-4a84-ba60-58245ee7406d-S63.48fe0555-83e9-4811-bcbc-f301da498fa6:80','ctl5-production_cleaner.6a86c5fa-7919-11e7-bc6c-ee0cf095fd00','ctl5-production_command-launcher.9f97a534-8413-11e7-bc6c-ee0cf095fd00','ctl5-production_reservation-manager.7ac1771d-7a9e-11e7-bc6c-ee0cf095fd00','ctl5-s 
    *** (2) HOLDS THE LOCK(S): 
    RECORD LOCKS space id 1485 page no 987 n bits 104 index `PRIMARY` of table `ctl`.`job_charge` trx table locks 1 total table locks 2 trx id 201691925 lock_mode X locks rec but not gap lock hold time 13 wait time before grant 12 
    *** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
    RECORD LOCKS space id 1485 page no 1606 n bits 88 index `PRIMARY` of table `ctl`.`job_charge` trx table locks 1 total table locks 2 trx id 201691925 lock_mode X locks rec but not gap waiting lock hold time 0 wait time before grant 0 
    *** WE ROLL BACK TRANSACTION (1) 

Answer 1

はい。両方とも異なる行でなければなりません。あなたは、トランザクション1ここで

文で示されているように無987と1606

ページを見ることができます

SELECT 
        re.*, 
        r.config_id, 
        r.reserve_all_or_nothing, 
        r.owner, 
        r.charges 
       FROM 
        `job_charge` AS re, 
        `job` AS r WHERE 
        re.job_id = r.id AND ((re.status ='dispatched') or (re.status= 'running') or (re.status= 'held') or (re.status= 'reserved')) AND ((re.service_id ='0')) AND r.disable = 0 ORDER BY r.priority,r.id LIMIT 10000 FOR UPDATE 

トランザクション2が与えられたメッセージから

UPDATE 
      `job_charge` 
     SET 
      service_id = '0' 
     WHERE 
      service_id NOT IN ('0','ctl5-staging_command-launcher.674d8c96-7c76-11e7-bc6c-ee0cf095fd00','inf-mesos-slave001.ctl.gdl.englab.netapp.com:mesos-6b256982-4ef1-4a84-ba60-58245ee7406d-S63.3987fd54-ee31-4c81-add4-4be53a6ed363:80','ctl5-staging_scheduler.912d008f-7c76-11e7-bc6c-ee0cf095fd00','ctl5-production_capacity-manager.6a869ee7-7919-11e7-bc6c-ee0cf095fd00','ctl5-production_scheduler.91de7d76-7919-11e7-bc6c-ee0cf095fd00','mysql','inf-mesos-slave001.ctl.gdl.englab.netapp.com:mesos-6b256982-4ef1-4a84-ba60-58245ee7406d-S63.48fe0555-83e9-4811-bcbc-f301da498fa6:80','ctl5-production_cleaner.6a86c5fa-7919-11e7-bc6c-ee0cf095fd00','ctl5-production_command-launcher.9f97a534-8413-11e7-bc6c-ee0cf095fd00','ctl5-production_reservation-manager.7ac1771d-7a9e-11e7-bc6c-ee0cf095fd00','ctl5-s 

です、私たちはそのトランザクション1を見ることができますテーブル 'ctl'主キーの排他ロック（Xロックで示され、テーブルに値を書き込むために必要なロック）を待機しています。

しかし、トランザクション2は、すでにのを保持していて、 'ctl'テーブルの主キー（987ページ）のXロックを保持しています。したがって、トランザクション2は既に 'ctl'にXロックを持っているので、トランザクション1はXロックを取得できないため、待機しています。

が、トランザクション2自体がは（無1606頁、上記とは異なる行）「CTL」に別のXロックをを待っていません。私は、この行が1.

ので、 トランザクション1が行のロックを保持しているため、トランザクション2が と トランザクション2を待っていない1606ページの行のロックを保持しているトランザクションによってを開催されていると思いますトランザクション1が待機しているページ番号987にありません。

したがって、両方ともお互いを待っているため、デッドロックが発生しました。