某天突然收到報(bào)警，數(shù)據(jù)庫大量事務(wù)等待，進(jìn)到數(shù)據(jù)庫后發(fā)線大量的插入操作被阻塞，且都是同一個(gè)表的。

通過 show engine innodb status 發(fā)現(xiàn)插入操作都是在等待索引 idx_create_time(create_time) 的 insert intention lock(跟 gap 鎖互斥)，由于某些原因數(shù)據(jù)庫是 RR 隔離級(jí)別。

RECORD LOCKS space id 764 page no 471030 n bits 968 index idx_create_time of table `fbs_fdc`.`fbs_sync_logs_taojj_goods` trx id 7007107746 lock_mode X insert intention waiting

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

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

1

2

3

RECORDLOCKSspaceid764pageno471030nbits968indexidx_create_timeoftable`fbs_fdc`.`fbs_sync_logs_taojj_goods`trxid7007107746lock_modeXinsertintentionwaiting

Recordlock,heapno1PHYSICALRECORD:n_fields1;compactformat;infobits0

0:len8;hex73757072656d756d;ascsupremum;;

當(dāng)時(shí)查了半天，也沒有發(fā)現(xiàn)跟這個(gè)表相關(guān)的其他操作。后面解決方案很狗血，下面再說。

后來查故障問題的時(shí)候，首先看了這個(gè)故障時(shí)間點(diǎn)跟這個(gè)表相關(guān)的操作。先發(fā)現(xiàn)了大量了 insert 操作(達(dá)到了數(shù)據(jù)庫默認(rèn)的 50s 鎖超時(shí))，如下圖。

所以確定了 insert 肯定都是在等待鎖，到底在等待什么鎖呢？當(dāng)時(shí)把跟這個(gè)表相關(guān)的所有語句都 kill 了，但是有遺漏，就是已經(jīng)執(zhí)行完但事務(wù)還沒有提交的 SQL。

然后從第一條 insert 報(bào)錯(cuò)的時(shí)間往后查找記錄，此時(shí)就發(fā)現(xiàn)了重要線索：

在同一個(gè)線程 ID 下先開啟了事務(wù)，然后對(duì) DELEET 操作做了一個(gè)執(zhí)行計(jì)劃，并且事務(wù)沒有提交(另外一個(gè)同事在 workbench 工具做的，忘記提交事務(wù))。并且從時(shí)間上來看，這個(gè)操作剛剛執(zhí)行完，insert 就開始報(bào)錯(cuò)了，所以基本肯定是事務(wù)沒有提交導(dǎo)致的了。

接著就是復(fù)現(xiàn)問題了，發(fā)現(xiàn)對(duì) DELETE 語句做 EXPLAIN 含有子查詢時(shí)，子查詢是加鎖的(沒有子查詢的沒有鎖)，我們看一下這條語句具體加什么鎖：

explain

DELETE

FROM fbs_fdc.fbs_sync_logs_taojj_goods

WHERE id<(

SELECT min_id

FROM(

SELECT MIN(id) min_id

FROM fbs_fdc.fbs_sync_logs_taojj_goods

WHERE create_time>=(UNIX_TIMESTAMP(DATE_ADD(NOW(), INTERVAL - 10 DAY)))) tmp)

1

2

3

4

5

6

7

8

9

explain

DELETE

FROMfbs_fdc.fbs_sync_logs_taojj_goods

WHEREid<(

SELECTmin_id

FROM(

SELECTMIN(id)min_id

FROMfbs_fdc.fbs_sync_logs_taojj_goods

WHEREcreate_time>=(UNIX_TIMESTAMP(DATE_ADD(NOW(),INTERVAL-10DAY))))tmp)

看子查詢可以知道，由于 create_time 字段是有索引的(上面鎖等待里面 idx_create_time 索引)，并且條件是查大于當(dāng)前時(shí)間減去 10 天的時(shí)間，由于是 RR 隔離級(jí)別，所以對(duì)大于這個(gè)時(shí)間的記錄都加了記錄鎖 + Gap鎖，且 Gap 鎖住了 (表最大記錄, supremum]。所以導(dǎo)致其他記錄都插入時(shí)，由于時(shí)間字段時(shí)單調(diào)遞增的，所以都被這個(gè) (表最大記錄, supremum] 區(qū)間鎖住了。如果插入的記錄時(shí)間是小于 (UNIX_TIMESTAMP(DATE_ADD(NOW(), INTERVAL – 10 DAY)))) 這個(gè)區(qū)間的話，就不會(huì)有問題了，因?yàn)闆]有被 Gap 鎖住。

對(duì)于上面的 EXPLAIN 來說，鎖的信息并不是那么明顯。如下所示：

---TRANSACTION 7063564148, ACTIVE 22 sec

962 lock struct(s), heap size 221392, 1076484 row lock(s)

MySQL thread id 151743704, OS thread handle 47149846046464, query id 16175417511 10.16.3.169 user_admin

1

2

3

---TRANSACTION7063564148,ACTIVE22sec

962lockstruct(s),heapsize221392,1076484rowlock(s)

MySQLthreadid151743704,OSthreadhandle47149846046464,queryid1617541751110.16.3.169user_admin

可以看到非常多的行鎖。

知道了這些信息之后，再來說當(dāng)時(shí)是怎么解決的。我同事在開啟的哪個(gè)事務(wù)里面執(zhí)行了一個(gè) rename table 操作，把表重命名了，然后重新創(chuàng)建了一張一樣的表就好了。因?yàn)槭窃谕粋€(gè)事務(wù)里面執(zhí)行的 EXPLAIN DELETE，所以 rename table 不需要等待鎖。如果在其他事務(wù)的話，rename table 也應(yīng)該被阻塞了。

如果您覺得本站對(duì)你有幫助，那么可以支付寶掃碼捐助以幫助本站更好地發(fā)展，在此謝過。

總結(jié)

以上是生活随笔為你收集整理的mysql排插问题_MySQL一次数据插入故障记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。