国产成人精品18p,天天干成人网,无码专区狠狠躁天天躁,美女脱精光隐私扒开免费观看

MySQL的RR模式下死鎖

發(fā)布時(shí)間：2021-08-27 12:16 來(lái)源：億速云 閱讀：0 作者：chen 欄目： Mysql 歡迎投稿：712375056

本篇內容主要講解“的RR模式下死鎖”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強。下面就讓小編來(lái)帶大家學(xué)習“MySQL的RR模式下死鎖”吧!

一、問(wèn)題提出

如下構造方式，問(wèn)為什么RC模式下不會(huì )死鎖，RR模式下死鎖。

drop table tt;
CREATE TABLE `tt` (  `id` int(11) NOT NULL,  `c1` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `c1` (`c1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
insert into tt values(1,1);

二、分析方式

首先分析session 1 第一句：

select * from tt where c1=1 for update;
執行后的加鎖行為

  • RR

---TRANSACTION 231106, ACTIVE 9 sec3 lock struct(s), heap size 1160, 2 row lock(s)
MySQL thread id 11, OS thread handle 140737153623808, query id 303 localhost root
TABLE LOCK table `test`.`tt` trx id 231106 lock mode IX
RECORD LOCKS space id 127 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231106 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 127 page no 3 n bits 72 index PRIMARY of table `test`.`tt` trx id 231106 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 0000000386c0; asc       ;; 2: len 7; hex aa0000003f0110; asc     ?  ;; 3: len 4; hex 80000001; asc     ;;

  • RC

---TRANSACTION 231105, ACTIVE 7 sec3 lock struct(s), heap size 1160, 2 row lock(s)
MySQL thread id 11, OS thread handle 140737153623808, query id 295 localhost root
TABLE LOCK table `test`.`tt` trx id 231105 lock mode IX
RECORD LOCKS space id 127 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231105 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 127 page no 3 n bits 72 index PRIMARY of table `test`.`tt` trx id 231105 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 0000000386c0; asc       ;; 2: len 7; hex aa0000003f0110; asc     ?  ;; 3: len 4; hex 80000001; asc     ;;

我們可以看到因為 c1是主鍵因此加鎖方式不管怎么樣都是LOCK_X|LOCK_REC_NOT_GAP，主鍵上也是同樣的。就是鎖住了二級唯一索引和主鍵的相關(guān)記錄。

然后分析session 1 第二句：

update tt set id=2 where c1=1;
執行后的加鎖行為

這一句比較重要，在二級唯一索引c1上會(huì )做一個(gè)刪除和插入操作，也就是會(huì )將原來(lái)的1,1記錄標記為del flag，同時(shí)插入2,1這條記錄，這會(huì )引起一個(gè)鎖的繼承操作(lock_rec_inherit_to_gap_if_gap_lock調用會(huì )出現GAP LOCK)，但是之前還會(huì )涉及到唯一性檢查因此還涉及到LOCK_S鎖和next key lock的存在(對于二級索引做唯一性檢查始終是next key lock)。這里的del flag也是形成死鎖的重要原因。(對于二級索引的update操作總是先刪除然后插入記錄，主鍵則會(huì )進(jìn)行判斷是否可以容下新的記錄)

  • RR

---TRANSACTION 231106, ACTIVE 1626 sec5 lock struct(s), heap size 1160, 5 row lock(s), undo log entries 2MySQL thread id 11, OS thread handle 140737153623808, query id 305 localhost root
TABLE LOCK table `test`.`tt` trx id 231106 lock mode IX
RECORD LOCKS space id 127 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231106 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 127 page no 3 n bits 72 index PRIMARY of table `test`.`tt` trx id 231106 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 0000000386c2; asc       ;; 2: len 7; hex 2c000000410dca; asc ,   A  ;; 3: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 127 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231106 lock mode S(LOCK_S) locks gap and rec(LOCK_ORDINARY[next_key_lock])
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 127 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231106 lock mode S(LOCK_S) locks gap before rec(LOCK_GAP)
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000002; asc     ;;

  • RC

5 lock struct(s), heap size 1160, 5 row lock(s), undo log entries 2MySQL thread id 11, OS thread handle 140737153623808, query id 316 localhost root
TABLE LOCK table `test`.`tt` trx id 231123 lock mode IX
RECORD LOCKS space id 128 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231123 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 128 page no 3 n bits 72 index PRIMARY of table `test`.`tt` trx id 231123 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 0000000386d3; asc       ;; 2: len 7; hex 370000003206e2; asc 7   2  ;; 3: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 128 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231123 lock mode S(LOCK_S) locks gap and rec(LOCK_ORDINARY[next_key_lock])
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
RECORD LOCKS space id 128 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231123 lock mode S(LOCK_S) locks gap before rec(LOCK_GAP)
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000002; asc     ;;

到這里RR和RC加鎖并沒(méi)有什么不同，因為都是唯一值，同時(shí)鎖繼承也都是二級索引上的都是LOCK_S|LOCK_ORDINARY[next_key_lock]，但是下面就會(huì )出現不同了。

然后分析session 2的第一句：

select * from tt where c1=1 for update;

實(shí)際上這個(gè)時(shí)候存在2條c1=1的記錄只有1,1標記為刪除了，1,2沒(méi)有提交，都是需要訪(fǎng)問(wèn)的。
然后堵塞行為為：

  • RR

LOCK WAIT 2 lock struct(s), heap size 1160, 1 row lock(s)
MySQL thread id 10, OS thread handle 140737153824512, query id 350 localhost root statistics
select * from tt where c1=1 for update
------- TRX HAS BEEN WAITING 11 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 129 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231146 lock_mode X(LOCK_X) locks gap and rec(LOCK_ORDINARY[next_key_lock]) waiting(LOCK_WAIT)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;

  • RC

LOCK WAIT 2 lock struct(s), heap size 1160, 1 row lock(s)
MySQL thread id 10, OS thread handle 140737153824512, query id 325 localhost root statistics
select * from tt where c1=1 for update
------- TRX HAS BEEN WAITING 9 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 128 page no 4 n bits 72 index c1 of table `test`.`tt` trx id 231128 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP) waiting(LOCK_WAIT)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;

我們這里可以看到對于RR模式下唯一鍵c1的1,1已經(jīng)刪除了。我做了debug發(fā)現這里會(huì )在函數中row_search_mvcc加鎖前做判斷如下：

if (!set_also_gap_locks            || srv_locks_unsafe_for_binlog            || trx->isolation_level <= TRX_ISO_READ_COMMITTED            || (unique_search && !rec_get_deleted_flag(rec, comp))            || dict_index_is_spatial(index)) {
            goto no_gap_lock;
        } else {
            lock_type = LOCK_ORDINARY;
        }

我們拋開(kāi)其他來(lái)分析這兩句

  • trx->isolation_level <= TRX_ISO_READ_COMMITTED
    如果是RC模式則直接上LOCK_REC_NOT_GAP及只鎖住記錄本身

  • (unique_search && !rec_get_deleted_flag(rec, comp))
    如果不是RC，如果是二級唯一索引并且沒(méi)有被標記為del flag則標記為L(cháng)OCK_REC_NOT_GAP。但是如果標記為del flag則標記為L(cháng)OCK_ORDINARY就是next key lock。

分析session 1的最后一個(gè)語(yǔ)句也就是產(chǎn)生死鎖的語(yǔ)句：

select * from tt where c1=1 for update;

如上這個(gè)語(yǔ)句會(huì )訪(fǎng)問(wèn)1,1標記為刪除了，1,2沒(méi)有提交 的兩個(gè)記錄。這個(gè)時(shí)候就出現了不同。

  • RC
    只需要唯一索引 1,1上 LOCK_REC_NOT_GAP|LOCK_X 及記錄索引，這個(gè)鎖在本事物的第一句語(yǔ)句上已經(jīng)獲得了，因此直接通過(guò)了，不需要做檢測。

  • RR

需要在唯一索引 1,1上 LOCK_ORDINARY|LOCK_X 也就是就是next key lock。這個(gè)鎖在本事物中并沒(méi)有獲取過(guò)，因此需要重新的檢測所的兼容性，最終加入了等待列表。

我們來(lái)看一下函數lock_rec_lock_slow，我做debug的時(shí)候明顯看到了不同的邏輯：

if (lock_rec_has_expl(mode, block, heap_no, trx)) { 
        /* The trx already has a strong enough lock on rec: do 1,1 key lock RR NEX KEY LOCK  stronager
        nothing */
        lock_rec_print(mode,block,heap_no,index,thr_get_trx(thr));
        err = DB_SUCCESS;
    } else {        const lock_t* wait_for = lock_rec_other_has_conflicting(
            mode, block, heap_no, trx,index);        if (wait_for != NULL) {            /* If another transaction has a non-gap conflicting
            request in the queue, as this transaction does not
            have a lock strong enough already granted on the
            record, we may have to wait. */
            RecLock rec_lock(thr, index, block, heap_no, mode);
            err = rec_lock.add_to_waitq(wait_for);
        }

三、總結

最終RR下形成了環(huán)路

  • session1 首先獲得唯一索引上的 1,1記錄的 LOCK_REC_NOT_GAP|LOCK_X

  • 然后session 1做update 獲得唯一索引上的 1,1記錄的 LOCK_ORDINARY(next key lock)|LOCK_S

  • 然后session 2需要獲取唯一索引上的 1,1記錄的 LOCK_ORDINARY(next key lock)|LOCK_X 發(fā)生等待

  • 然后session 1需要獲取唯一索引上的 1,1記錄的 LOCK_ORDINARY(next key lock)|LOCK_X 加入等待隊列進(jìn)行等待

死鎖發(fā)生因此發(fā)生，而RC模式下最后兩部需要獲取的都是 LOCK_REC_NOT_GAP|LOCK_X，雖然session 2處于等待但是session因為已經(jīng)獲得相同級別的鎖不會(huì )在進(jìn)行檢測加鎖等待，而直接通過(guò)了。

下面是死鎖的記錄：

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 117 page no 4 n bits 72 index c1 of table `t1`.`tt` trx id 230530 lock_mode X(LOCK_X) locks gap and rec(LOCK_ORDINARY[next_key_lock]) waiting(LOCK_WAIT)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
*** (2) TRANSACTION:
TRANSACTION 230525, ACTIVE 68 sec starting index read
mysql tables in use 1, locked 16 lock struct(s), heap size 1160, 6 row lock(s), undo log entries 2MySQL thread id 6, OS thread handle 140737153423104, query id 156 localhost root statistics
select * from tt where c1=1 for update
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 117 page no 4 n bits 72 index c1 of table `t1`.`tt` trx id 230525 lock_mode X(LOCK_X) locks rec but not gap(LOCK_REC_NOT_GAP)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 117 page no 4 n bits 72 index c1 of table `t1`.`tt` trx id 230525 lock_mode X(LOCK_X) locks gap and rec(LOCK_ORDINARY[next_key_lock]) waiting(LOCK_WAIT)
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;; 1: len 4; hex 80000001; asc     ;;
*** WE ROLL BACK TRANSACTION (1)

四、棧幀參考

最后留下幾個(gè)棧幀以備分析使用

  • 鎖繼承

#0  lock_rec_set_nth_bit (lock=0x30b1230, i=3) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/include/lock0priv.ic:91#1  0x0000000001a5d44a in RecLock::lock_alloc (trx=0x7fffd7803b10, index=0x7ffe7459ff80, mode=546, rec_id=..., size=9)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:1484#2  0x0000000001a5d826 in RecLock::create (this=0x7fffec0c0eb0, trx=0x7fffd7803b10, owns_trx_mutex=false, add_to_hash=true, prdt=0x0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:1537#3  0x0000000001a5e60c in lock_rec_add_to_queue (type_mode=546, block=0x7fff9adb8150, heap_no=3, index=0x7ffe7459ff80, trx=0x7fffd7803b10, 
    caller_owns_trx_mutex=false) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:1853#4  0x0000000001a611ec in lock_rec_inherit_to_gap_if_gap_lock (block=0x7fff9adb8150, heir_heap_no=3, heap_no=1)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:2829#5  0x0000000001a62ea3 in lock_update_insert (block=0x7fff9adb8150, rec=0x7fff9b9c408c "\200")
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:3659#6  0x0000000001c53c25 in btr_cur_optimistic_insert (flags=0, cursor=0x7fffec0c23f0, offsets=0x7fffec0c24c8, heap=0x7fffec0c13e0, entry=0x7ffe7403bb70, 
    rec=0x7fffec0c24c0, big_rec=0x7fffec0c24b8, n_ext=0, thr=0x7ffe7403ba00, mtr=0x7fffec0c1bc0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/btr/btr0cur.cc:3346#7  0x0000000001b195fe in row_ins_sec_index_entry_low (flags=0, mode=2, index=0x7ffe7459ff80, offsets_heap=0x7ffe7403bf98, heap=0x7ffe7403c448, entry=0x7ffe7403bb70, 
    trx_id=0, thr=0x7ffe7403ba00, dup_chk_only=false) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0ins.cc:3166#8  0x0000000001b1a15e in row_ins_sec_index_entry (index=0x7ffe7459ff80, entry=0x7ffe7403bb70, thr=0x7ffe7403ba00, dup_chk_only=false)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0ins.cc:3421#9  0x0000000001b9e053 in row_upd_sec_index_entry (node=0x7ffe7403b6f8, thr=0x7ffe7403ba00)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0upd.cc:2337#10 0x0000000001b9e1c3 in row_upd_sec_step (node=0x7ffe7403b6f8, thr=0x7ffe7403ba00)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0upd.cc:2364

  • RR加鎖del flag記錄

#0  lock_rec_set_nth_bit (lock=0x30b28b8, i=2) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/include/lock0priv.ic:91#1  0x0000000001a5d44a in RecLock::lock_alloc (trx=0x7fffd7804080, index=0x7ffe74064ea0, mode=259, rec_id=..., size=9)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:1484#2  0x0000000001a5d826 in RecLock::create (this=0x7fffec0c1e00, trx=0x7fffd7804080, owns_trx_mutex=true, add_to_hash=true, prdt=0x0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:1537#3  0x0000000001a5e1c4 in RecLock::add_to_waitq (this=0x7fffec0c1e00, wait_for=0x30b0e58, prdt=0x0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:1731#4  0x0000000001a5ee37 in lock_rec_lock_slow (impl=0, mode=3, block=0x7fff4d027b20, heap_no=2, index=0x7ffe74064ea0, thr=0x7ffe7459ff60)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:2004#5  0x0000000001a5f1ce in lock_rec_lock (impl=false, mode=3, block=0x7fff4d027b20, heap_no=2, index=0x7ffe74064ea0, thr=0x7ffe7459ff60)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:2082#6  0x0000000001a69a02 in lock_sec_rec_read_check_and_lock (flags=0, block=0x7fff4d027b20, rec=0x7fff4da8c07e "\200", index=0x7ffe74064ea0, offsets=0x7fffec0c2690, 
    mode=LOCK_X, gap_mode=0, thr=0x7ffe7459ff60) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:6457#7  0x0000000001b717f7 in sel_set_rec_lock (pcur=0x7ffe7459f6d0, rec=0x7fff4da8c07e "\200", index=0x7ffe74064ea0, offsets=0x7fffec0c2690, mode=3, type=0, 
    thr=0x7ffe7459ff60, mtr=0x7fffec0c2180) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:1270#8  0x0000000001b7ab6a in row_search_mvcc (buf=0x7ffe7405b9c0 "\375\002", mode=PAGE_CUR_GE, prebuilt=0x7ffe7459f4b0, match_mode=1, direction=0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:5591

  • RC加鎖del flag記錄

#0  lock_rec_lock_slow (impl=0, mode=1027, block=0x7fff3310cdf0, heap_no=2, index=0x7ffe74076d90, thr=0x7ffe7459fc20)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:1962#1  0x0000000001a5f1ce in lock_rec_lock (impl=false, mode=1027, block=0x7fff3310cdf0, heap_no=2, index=0x7ffe74076d90, thr=0x7ffe7459fc20)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:2082#2  0x0000000001a69a02 in lock_sec_rec_read_check_and_lock (flags=0, block=0x7fff3310cdf0, rec=0x7fff33bdc07e "\200", index=0x7ffe74076d90, offsets=0x7fffec0c2690, 
    mode=LOCK_X, gap_mode=1024, thr=0x7ffe7459fc20) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/lock/lock0lock.cc:6457#3  0x0000000001b717f7 in sel_set_rec_lock (pcur=0x7ffe7459f6d0, rec=0x7fff33bdc07e "\200", index=0x7ffe74076d90, offsets=0x7fffec0c2690, mode=3, type=1024, 
    thr=0x7ffe7459fc20, mtr=0x7fffec0c2180) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:1270#4  0x0000000001b7ab6a in row_search_mvcc (buf=0x7ffe7403ae80 "\375\002", mode=PAGE_CUR_GE, prebuilt=0x7ffe7459f4b0, match_mode=1, direction=0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:5591#5  0x00000000019d5493 in ha_innobase::index_read (this=0x7ffe7403cda0, buf=0x7ffe7403ae80 "\375\002", key_ptr=0x7ffe74095600 "", key_len=5, 
    find_flag=HA_READ_KEY_EXACT) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:9536#6  0x0000000000f934aa in handler::index_read_map (this=0x7ffe7403cda0, buf=0x7ffe7403ae80 "\375\002", key=0x7ffe74095600 "", keypart_map=1, 
    find_flag=HA_READ_KEY_EXACT) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/handler.h:2942

免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng )、來(lái)自本網(wǎng)站內容采集于網(wǎng)絡(luò )互聯(lián)網(wǎng)轉載等其它媒體和分享為主，內容觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如侵犯了原作者的版權，請告知一經(jīng)查實(shí)，將立刻刪除涉嫌侵權內容，聯(lián)系我們QQ:712375056，同時(shí)歡迎投稿傳遞力量。

  • 100倍故障賠償
  • 1天無(wú)理由退款
  • 7x24小時(shí)服務(wù)
  • 0元快速備案
  • 1V1專(zhuān)席秘書(shū)
超碰97久久国产精品牛牛| 日日AV色欲香天天综合网| 亚洲爆乳精品无码AAA片| 免费的成人A级毛片| 97精品伊人久久大香线蕉| 国产a国产片国产|