Innodb更新鎖定

Question

我一直有一個特定的更新查詢，這似乎應該是非常沒有問題的各種麻煩。我已經改變了名稱，但該表是：

CREATE TABLE `problem_table` (
    `id` int(11) NOT NULL, 
    `type` enum('TYPE1','TYPE2','TYPE3') NOT NULL, 
    `date` datetime NOT NULL, 
    `reference_id` int(11) DEFAULT NULL, 
    `value` varchar(255) NOT NULL, 
    `source` varchar(16) DEFAULT NULL, 
    `problem_field` datetime DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    KEY `type_idx` (`type`), 
    KEY `value_idx` (`value`(12)), 
    KEY `latest_id` (`reference_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 

和查詢造成的問題是：

UPDATE problem_table SET problem_field = 20000101 WHERE id = 6526153; 

值的problem_field和id這裏就不似乎是很重要的。

這個單一的更新是在problem_table上的各種選擇查詢反覆死鎖，所以我的問題是 - 這個簡單的更新查詢取出了什麼鎖？我應該補充說，這兩個死鎖事務只包含單個查詢。

我已閱讀the docs但他們似乎並不特別全面。

供參考，在這裏是它和它的INNODB狀態報告死鎖的查詢，雖然這僅僅是一個例子了許多不同的查詢：

INSERT INTO temp 
SELECT 
    p.*, 
    DATE(p.date) 
FROM 
    problem_table p 
WHERE p.type IN ('TYPE1', 'TYPE2') 
    AND p.source = 'FOO'; 


------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
161107 0:00:00 
*** (1) TRANSACTION: 
TRANSACTION 3C7788A94, ACTIVE 69 sec starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 10 lock struct(s), heap size 1248, 7 row lock(s), undo log entries 6 
MySQL thread id 6558222, OS thread handle 0x7f44a606d700, query id 3110073624 164.55.80.105 sym_dbuser Updating 
-- user=XXX progname=XXX host=XXX pid=XXX ldsn=XXX 
-- DBI::db=HASH(0x1d15ecb0) 
UPDATE problem_table SET problem_field = 'XXXX-XX-XX XX:XX:XX'WHERE id = 'XXXXX' 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 1069083 page no 313 n bits 280 index `PRIMARY` of table `XXX`.`problem_table` trx id 3C7788A94 lock_mode X locks rec but not gap waiting 
*** (2) TRANSACTION: 
TRANSACTION 3C766F450, ACTIVE 831 sec fetching rows, thread declared inside InnoDB 39 
mysql tables in use 2, locked 2 
47612 lock struct(s), heap size 5339576, 9395927 row lock(s), undo log entries 9194153 
MySQL thread id 6558799, OS thread handle 0x7f4203cb6700, query id 3108758081 172.29.1.16 XXX Sending data 
-- user=XXX progname=XXX host=XXX pid=XXX ldsn=sym@symprod 

INSERT INTO temp 
SELECT 
    p.*, 
    DATE(p.date) 
FROM 
    problem_table p 
WHERE p.type IN ('TYPE1', 'TYPE2') 
    AND p.source = 'FOO'; 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 1069083 page no 313 n bits 280 index `PRIMARY` of table `XXX`.`problem_table` trx id 3C766F450 lock mode S 
*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 1069083 page no 82008 n bits 280 index `PRIMARY` of table `XXX`.`problem_table` trx id 3C766F450 lock mode S waiting 
*** WE ROLL BACK TRANSACTION (2) 

編輯：

對於任何人的利益讀下來，我發現INNODB能夠檢測3個或更多事務的死鎖，但它只列出受害者和希望受害者鎖定在死鎖報告中的事務 - 其餘事務不是在那裏列出。

看到這一點，運行三個交易，如：

T(ransaction)1 take S lock on R(ecord) 1 
T2 take S lock on R2 
T2 take X lock on R1 (hangs waiting for T1) 
T3 take S lock on R3 
T3 take X lock on R2 (hangs waiting for T2) 
T1 take X lock on R3 (deadlock detected) 

Answer 1

要回答這個問題埋在中間有一個基本問題，通過

UPDATE problem_table SET problem_field = 20000101 WHERE id = 6526153; 

其中problem_table被定義爲在問題中取出鎖只是：

• 上的IX lockproblem_table
• 有記錄X lock

事實證明，事情並不像我之前所描述的那樣 - 工具1執行有問題的更新不會執行事務管理，因此所有更新通常都會形成自己的事務。

但是，在這種情況下，有一個工具2，它使用工具1，並將其所有操作包裝在自己的事務中。因此，這個單一更新畢竟是更大事務的一部分（包含同一表中另一行的更新）。

這使得它更清晰地解釋爲什麼會發生死鎖 - 正在實施的修復是按照主鍵的順序進行這兩個更新（在這種類型的死鎖here上有一個很好的帖子）。

我也會考慮@fancyPants建議的一些模式更改，雖然這需要更多的工作 - 我提供的示例相當簡單，表格設計總體上非常可怕。它可以肯定使用一些sprucing ...

Answer 2

這是因爲你沒有使用你的INSERT ... SELECT查詢的良好指標。

你有一個索引type，但這是（我猜）完全沒用。此列只能有3個不同的值。你的查詢甚至要求2中的3個。索引越好，選擇性越高。換句話說，這個距離越近，

SELECT COUNT(DISTINCT columnname)/COUNT(*) FROM yourtable; 

是1，最好是你的指數。

這裏使用索引太貴，因爲實際上它需要MySQL首先讀取索引，然後再讀取實際數據。因此，閱讀整個表格會更便宜。

對於您的情況，source的索引會更好。或者甚至是(source, type)的綜合指數。 （順序在這裏很重要，首先選擇性更強！）