青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

兔子的技術(shù)博客

兔子

   :: 首頁(yè) :: 聯(lián)系 :: 聚合  :: 管理
  202 Posts :: 0 Stories :: 43 Comments :: 0 Trackbacks

留言簿(10)

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

摘自 

《深入淺出MySQL——數(shù)據(jù)庫(kù)開發(fā)、優(yōu)化與管理維護(hù)》

20.3.3 InnoDB的行鎖模式及加鎖方法

InnoDB實(shí)現(xiàn)了以下兩種類型的行鎖。 

? 共享鎖(S):允許一個(gè)事務(wù)去讀一行,阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖。

? 排他鎖(X):允許獲得排他鎖的事務(wù)更新數(shù)據(jù),阻止其他事務(wù)取得相同數(shù)據(jù)集的共享讀鎖和排他寫鎖。

另外,為了允許行鎖和表鎖共存,實(shí)現(xiàn)多粒度鎖機(jī)制,InnoDB還有兩種內(nèi)部使用的意向鎖(Intention Locks),這兩種意向鎖都是表鎖。

? 意向共享鎖(IS):事務(wù)打算給數(shù)據(jù)行加行共享鎖,事務(wù)在給一個(gè)數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖。

? 意向排他鎖(IX):事務(wù)打算給數(shù)據(jù)行加行排他鎖,事務(wù)在給一個(gè)數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。

上述鎖模式的兼容情況具體如表20-6所示。

表20-6     InnoDB行鎖模式兼容性列表

請(qǐng)求鎖模式

 

   是否兼容

 

當(dāng)前鎖模式

X

IX

S

IS

X

沖突

沖突

沖突

沖突

IX

沖突

兼容

沖突

兼容

S

沖突

沖突

兼容

兼容

IS

沖突

兼容

兼容

兼容

如果一個(gè)事務(wù)請(qǐng)求的鎖模式與當(dāng)前的鎖兼容,InnoDB就將請(qǐng)求的鎖授予該事務(wù);反之,如果兩者不兼容,該事務(wù)就要等待鎖釋放。

意向鎖是InnoDB自動(dòng)加的,不需用戶干預(yù)。對(duì)于UPDATE、DELETE和INSERT語(yǔ)句,InnoDB會(huì)自動(dòng)給涉及數(shù)據(jù)集加排他鎖(X);對(duì)于普通SELECT語(yǔ)句,InnoDB不會(huì)加任何鎖;事務(wù)可以通過以下語(yǔ)句顯示給記錄集加共享鎖或排他鎖。

·共享鎖(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。

·排他鎖(X):SELECT * FROM table_name WHERE ... FOR UPDATE。

用SELECT ... IN SHARE MODE獲得共享鎖,主要用在需要數(shù)據(jù)依存關(guān)系時(shí)來(lái)確認(rèn)某行記錄是否存在,并確保沒有人對(duì)這個(gè)記錄進(jìn)行UPDATE或者DELETE操作。但是如果當(dāng)前事務(wù)也需要對(duì)該記錄進(jìn)行更新操作,則很有可能造成死鎖,對(duì)于鎖定行記錄后需要進(jìn)行更新操作的應(yīng)用,應(yīng)該使用SELECT... FOR UPDATE方式獲得排他鎖。

在如表20-7所示的例子中,使用了SELECT ... IN SHARE MODE加鎖后再更新記錄,看看會(huì)出現(xiàn)什么情況,其中actor表的actor_id字段為主鍵。

表20-7           InnoDB存儲(chǔ)引擎的共享鎖例子

session_1

session_2

mysql> set autocommit = 0;

Query OK, 0 rows affected (0.00 sec)

 

mysql> select actor_id,first_name,last_name from actor where actor_id = 178;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.00 sec)

mysql> set autocommit = 0;

Query OK, 0 rows affected (0.00 sec)

 

mysql> select actor_id,first_name,last_name from actor where actor_id = 178;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.00 sec)

當(dāng)前session對(duì)actor_id=178的記錄加share mode 的共享鎖:

mysql> select actor_id,first_name,last_name from actor where actor_id = 178 lock in share mode;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.01 sec)

 

 

其他session仍然可以查詢記錄,并也可以對(duì)該記錄加share mode的共享鎖:

mysql> select actor_id,first_name,last_name from actor where actor_id = 178 lock in share mode;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.01 sec)

當(dāng)前session對(duì)鎖定的記錄進(jìn)行更新操作,等待鎖:

mysql> update actor set last_name = 'MONROE T' where actor_id = 178;

等待

 

 

其他session也對(duì)該記錄進(jìn)行更新操作,則會(huì)導(dǎo)致死鎖退出:

mysql> update actor set last_name = 'MONROE T' where actor_id = 178;

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

獲得鎖后,可以成功更新:

mysql> update actor set last_name = 'MONROE T' where actor_id = 178;

Query OK, 1 row affected (17.67 sec)

Rows matched: 1  Changed: 1 Warnings: 0

 

當(dāng)使用SELECT...FOR UPDATE加鎖后再更新記錄,出現(xiàn)如表20-8所示的情況。

表20-8             InnoDB存儲(chǔ)引擎的排他鎖例子

session_1

session_2

mysql> set autocommit = 0;

Query OK, 0 rows affected (0.00 sec)

 

mysql> select actor_id,first_name,last_name from actor where actor_id = 178;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.00 sec)

mysql> set autocommit = 0;

Query OK, 0 rows affected (0.00 sec)

 

mysql> select actor_id,first_name,last_name from actor where actor_id = 178;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.00 sec)

當(dāng)前session對(duì)actor_id=178的記錄加for update的共享鎖:

mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.00 sec)

 

 

其他session可以查詢?cè)撚涗洠遣荒軐?duì)該記錄加共享鎖,會(huì)等待獲得鎖:

mysql> select actor_id,first_name,last_name from actor where actor_id = 178;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE   |

+----------+------------+-----------+

1 row in set (0.00 sec)

 

mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update;

等待

當(dāng)前session可以對(duì)鎖定的記錄進(jìn)行更新操作,更新后釋放鎖:

mysql> update actor set last_name = 'MONROE T' where actor_id = 178;

Query OK, 1 row affected (0.00 sec)

Rows matched: 1  Changed: 1 Warnings: 0

 

mysql> commit;

Query OK, 0 rows affected (0.01 sec)

 

 

其他session獲得鎖,得到其他session提交的記錄:

mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update;

+----------+------------+-----------+

| actor_id | first_name | last_name |

+----------+------------+-----------+

| 178      | LISA       | MONROE T |

+----------+------------+-----------+

1 row in set (9.59 sec)

 

 20.3.4 InnoDB行鎖實(shí)現(xiàn)方式

InnoDB行鎖是通過給索引上的索引項(xiàng)加鎖來(lái)實(shí)現(xiàn)的,這一點(diǎn)MySQL與Oracle不同,后者是通過在數(shù)據(jù)塊中對(duì)相應(yīng)數(shù)據(jù)行加鎖來(lái)實(shí)現(xiàn)的。InnoDB這種行鎖實(shí)現(xiàn)特點(diǎn)意味著:只有通過索引條件檢索數(shù)據(jù),InnoDB才使用行級(jí)鎖,否則,InnoDB將使用表鎖!

在實(shí)際應(yīng)用中,要特別注意InnoDB行鎖的這一特性,不然的話,可能導(dǎo)致大量的鎖沖突,從而影響并發(fā)性能。下面通過一些實(shí)際例子來(lái)加以說(shuō)明。

(1)在不通過索引條件查詢的時(shí)候,InnoDB確實(shí)使用的是表鎖,而不是行鎖。

在如表20-9所示的例子中,開始tab_no_index表沒有索引:

mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb;
Query OK, 0 rows affected (0.15 sec)
mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

表20-9         InnoDB存儲(chǔ)引擎的表在不使用索引時(shí)使用表鎖例子

session_1

session_2

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from tab_no_index where id = 1 ;

+------+------+

| id   | name |

+------+------+

| 1    | 1    |

+------+------+

1 row in set (0.00 sec)

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from tab_no_index where id = 2 ;

+------+------+

| id   | name |

+------+------+

| 2    | 2    |

+------+------+

1 row in set (0.00 sec)

mysql> select * from tab_no_index where id = 1 for update;

+------+------+

| id   | name |

+------+------+

| 1    | 1    |

+------+------+

1 row in set (0.00 sec)

 

 

mysql> select * from tab_no_index where id = 2 for update;

等待

在如表20-9所示的例子中,看起來(lái)session_1只給一行加了排他鎖,但session_2在請(qǐng)求其他行的排他鎖時(shí),卻出現(xiàn)了鎖等待!原因就是在沒有索引的情況下,InnoDB只能使用表鎖。當(dāng)我們給其增加一個(gè)索引后,InnoDB就只鎖定了符合條件的行,如表20-10所示。

創(chuàng)建tab_with_index表,id字段有普通索引:

mysql> create table tab_with_index(id int,name varchar(10)) engine=innodb;
Query OK, 0 rows affected (0.15 sec)
mysql> alter table tab_with_index add index id(id);
Query OK, 4 rows affected (0.24 sec)
Records: 4  Duplicates: 0  Warnings: 0

表20-10    InnoDB存儲(chǔ)引擎的表在使用索引時(shí)使用行鎖例子

session_1

session_2

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from tab_with_index where id = 1 ;

+------+------+

| id   | name |

+------+------+

| 1    | 1    |

+------+------+

1 row in set (0.00 sec)

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from tab_with_index where id = 2 ;

+------+------+

| id   | name |

+------+------+

| 2    | 2    |

+------+------+

1 row in set (0.00 sec)

mysql> select * from tab_with_index where id = 1 for update;

+------+------+

| id   | name |

+------+------+

| 1    | 1    |

+------+------+

1 row in set (0.00 sec)

 

 

mysql> select * from tab_with_index where id = 2 for update;

+------+------+

| id   | name |

+------+------+

| 2    | 2    |

+------+------+

1 row in set (0.00 sec)

(2)由于MySQL的行鎖是針對(duì)索引加的鎖,不是針對(duì)記錄加的鎖,所以雖然是訪問不同行的記錄,但是如果是使用相同的索引鍵,是會(huì)出現(xiàn)鎖沖突的。應(yīng)用設(shè)計(jì)的時(shí)候要注意這一點(diǎn)。

在如表20-11所示的例子中,表tab_with_index的id字段有索引,name字段沒有索引:

mysql> alter table tab_with_index drop index name;
Query OK, 4 rows affected (0.22 sec)
Records: 4  Duplicates: 0  Warnings: 0
mysql> insert into tab_with_index  values(1,'4');
Query OK, 1 row affected (0.00 sec)
mysql> select * from tab_with_index where id = 1;
+------+------+
| id   | name |
+------+------+
| 1    | 1    |
| 1    | 4    |
+------+------+
2 rows in set (0.00 sec)

表20-11    InnoDB存儲(chǔ)引擎使用相同索引鍵的阻塞例子

session_1

session_2

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from tab_with_index where id = 1 and name = '1' for update;

+------+------+

| id   | name |

+------+------+

| 1    | 1    |

+------+------+

1 row in set (0.00 sec)

 

 

雖然session_2訪問的是和session_1不同的記錄,但是因?yàn)槭褂昧讼嗤乃饕孕枰却i:

mysql> select * from tab_with_index where id = 1 and name = '4' for update;

等待

(3)當(dāng)表有多個(gè)索引的時(shí)候,不同的事務(wù)可以使用不同的索引鎖定不同的行,另外,不論是使用主鍵索引、唯一索引或普通索引,InnoDB都會(huì)使用行鎖來(lái)對(duì)數(shù)據(jù)加鎖。

在如表20-12所示的例子中,表tab_with_index的id字段有主鍵索引,name字段有普通索引:

mysql> alter table tab_with_index add index name(name);
Query OK, 5 rows affected (0.23 sec)
Records: 5  Duplicates: 0  Warnings: 0

表20-12    InnoDB存儲(chǔ)引擎的表使用不同索引的阻塞例子

·          session_1

·          session_2

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> set autocommit=0;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from tab_with_index where id = 1 for update;

+------+------+

| id   | name |

+------+------+

| 1    | 1    |

| 1    | 4    |

+------+------+

2 rows in set (0.00 sec)

 

 

Session_2使用name的索引訪問記錄,因?yàn)橛涗洓]有被索引,所以可以獲得鎖:

mysql> select * from tab_with_index where name = '2' for update;

+------+------+

| id   | name |

+------+------+

| 2    | 2    |

+------+------+

1 row in set (0.00 sec)

 

由于訪問的記錄已經(jīng)被session_1鎖定,所以等待獲得鎖。:

mysql> select * from tab_with_index where name = '4' for update;

(4)即便在條件中使用了索引字段,但是否使用索引來(lái)檢索數(shù)據(jù)是由MySQL通過判斷不同執(zhí)行計(jì)劃的代價(jià)來(lái)決定的,如果MySQL認(rèn)為全表掃描效率更高,比如對(duì)一些很小的表,它就不會(huì)使用索引,這種情況下InnoDB將使用表鎖,而不是行鎖。因此,在分析鎖沖突時(shí),別忘了檢查SQL的執(zhí)行計(jì)劃,以確認(rèn)是否真正使用了索引。關(guān)于MySQL在什么情況下不使用索引的詳細(xì)討論,參見本章“索引問題”一節(jié)的介紹。

在下面的例子中,檢索值的數(shù)據(jù)類型與索引字段不同,雖然MySQL能夠進(jìn)行數(shù)據(jù)類型轉(zhuǎn)換,但卻不會(huì)使用索引,從而導(dǎo)致InnoDB使用表鎖。通過用explain檢查兩條SQL的執(zhí)行計(jì)劃,我們可以清楚地看到了這一點(diǎn)。

例子中tab_with_index表的name字段有索引,但是name字段是varchar類型的,如果where條件中不是和varchar類型進(jìn)行比較,則會(huì)對(duì)name進(jìn)行類型轉(zhuǎn)換,而執(zhí)行的全表掃描。

mysql> alter table tab_no_index add index name(name);
Query OK, 4 rows affected (8.06 sec)
Records: 4  Duplicates: 0  Warnings: 0
mysql> explain select * from tab_with_index where name = 1 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tab_with_index
type: ALL
possible_keys: name
key: NULL
key_len: NULL
ref: NULL
rows: 4
Extra: Using where
1 row in set (0.00 sec)
mysql> explain select * from tab_with_index where name = '1' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tab_with_index
type: ref
possible_keys: name
key: name
key_len: 23
ref: const
rows: 1
Extra: Using where
1 row in set (0.00 sec)

標(biāo)簽: Mysql事務(wù)
轉(zhuǎn)自:
http://www.cnblogs.com/zhizhesky/articles/2164089.html
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美成年人在线观看| 午夜激情综合网| 国产婷婷色综合av蜜臀av | 久久久久久夜精品精品免费| 欧美jizz19hd性欧美| 久久国产综合精品| 国产精品大片免费观看| 亚洲电影在线观看| 激情视频一区二区三区| 亚洲一区二区在线播放| 亚洲一区二区三区四区在线观看| 玖玖精品视频| 欧美成人精品| 在线日韩电影| 久久久av网站| 久久亚洲精品中文字幕冲田杏梨 | 国产精品v亚洲精品v日韩精品| 老司机免费视频一区二区| 国产欧美一区二区精品忘忧草| 99国内精品久久| 亚洲乱码国产乱码精品精98午夜| 久久久久久亚洲综合影院红桃 | 欧美日韩成人在线播放| 亚洲国产精品久久人人爱蜜臀| 亚洲激情偷拍| 欧美成人精品一区| 亚洲激情欧美激情| av成人毛片| 欧美午夜一区二区| 亚洲永久精品国产| 欧美与黑人午夜性猛交久久久| 国产精品资源在线观看| 性视频1819p久久| 久久只精品国产| 亚洲国产精品综合| 欧美日韩国产天堂| 亚洲一级在线| 久久久久久久久久码影片| 狠狠色狠狠色综合日日tαg| 久久日韩精品| 亚洲人精品午夜| 亚洲一区二区少妇| 国产精品一区二区久久久| 性伦欧美刺激片在线观看| 久久久www免费人成黑人精品| 国精品一区二区三区| 久久免费视频在线| 亚洲精品免费电影| 欧美在线资源| 亚洲黄色片网站| 国产精品久久二区| 久久精品最新地址| 亚洲另类自拍| 久久国产婷婷国产香蕉| 亚洲国产精品久久久久秋霞蜜臀| 欧美精品二区三区四区免费看视频| 日韩视频精品在线| 久久久久久欧美| 99精品久久久| 国产自产女人91一区在线观看| 欧美成人按摩| 亚洲欧美日韩在线不卡| 欧美大片免费久久精品三p| 亚洲深夜福利| 亚洲第一页在线| 国产精品乱码一区二三区小蝌蚪| 久久欧美中文字幕| 这里只有精品丝袜| 欧美国产视频一区二区| 香蕉亚洲视频| 99在线精品免费视频九九视| 国产亚洲一区二区三区| 欧美日韩中文字幕| 麻豆精品精华液| 亚洲欧美99| 日韩亚洲国产精品| 亚洲高清色综合| 欧美日韩视频第一区| 午夜日本精品| 一区二区三区视频观看| 亚洲国产高清高潮精品美女| 久久久精彩视频| 国产精品久久福利| 欧美人妖另类| 久久精品亚洲一区二区| 日韩视频免费看| 免费亚洲一区二区| 久久9热精品视频| 亚洲综合成人婷婷小说| 日韩一级黄色av| 亚洲国产精品专区久久| 国模精品娜娜一二三区| 国产精品久久久久久久久久免费看| 免费欧美视频| 免费成人高清在线视频| 久久久亚洲精品一区二区三区| 午夜国产精品影院在线观看| 亚洲最新中文字幕| 亚洲欧洲另类国产综合| 欧美激情一区二区三区在线视频观看| 久久福利影视| 久久超碰97中文字幕| 先锋a资源在线看亚洲| 亚洲永久免费av| 亚洲在线成人精品| 亚洲欧美视频一区二区三区| 亚洲欧美国产精品专区久久| 中文一区二区| 中文日韩电影网站| 亚洲自拍偷拍网址| 性伦欧美刺激片在线观看| 午夜精品久久久久久久99水蜜桃| 亚洲影院污污.| 性久久久久久久久久久久| 香蕉久久夜色精品| 久久精品夜色噜噜亚洲a∨| 先锋影音久久久| 久久精品综合一区| 蜜桃av一区二区三区| 免费观看不卡av| 亚洲人成在线观看网站高清| 夜色激情一区二区| 亚洲综合色婷婷| 欧美诱惑福利视频| 麻豆免费精品视频| 欧美日韩亚洲视频| 国产精品亚洲欧美| 激情视频一区二区| 亚洲精品偷拍| 亚洲综合国产| 久久久久综合| 亚洲区中文字幕| 亚洲你懂的在线视频| 久久久久国产精品人| 欧美电影打屁股sp| 国产精品高精视频免费| 国产自产v一区二区三区c| 亚洲黄色在线| 先锋a资源在线看亚洲| 久久综合一区| 一区二区三区免费看| 久久国产精品久久久久久久久久 | 韩国av一区| 日韩一区二区精品视频| 性色一区二区| 在线日本欧美| 国产精品99久久久久久有的能看| 亚洲欧美视频在线| 欧美成人精品1314www| 99热这里只有精品8| 欧美诱惑福利视频| 欧美视频日韩| 亚洲第一精品久久忘忧草社区| 一区二区三区四区蜜桃| 久久久久久亚洲精品杨幂换脸 | 亚洲影院色无极综合| 久久午夜激情| 亚洲一区二区三区777| 你懂的国产精品| 国产日韩欧美在线一区| 一本色道久久综合亚洲精品婷婷| 欧美专区在线观看一区| 99精品久久久| 久久综合亚州| 国产一区二区黄| 亚洲砖区区免费| 亚洲国产精品一区二区第一页| 欧美一级久久| 国产精品久久久久99| 亚洲免费精彩视频| 老司机精品视频网站| 亚洲欧美www| 国产精品久久国产精品99gif| 亚洲激情在线观看| 久久久久久久高潮| 亚洲欧美日韩直播| 欧美性猛交xxxx免费看久久久| 亚洲精品看片| 欧美成人免费全部观看天天性色| 欧美怡红院视频一区二区三区| 欧美日韩一区不卡| 夜夜嗨网站十八久久| 亚洲国产成人精品女人久久久| 久久久精品999| 国产自产v一区二区三区c| 欧美一区二区视频在线观看| 亚洲视频成人| 国产精品久久久久久亚洲毛片| 亚洲一区二区日本| 99精品黄色片免费大全| 欧美日韩调教| 亚洲无吗在线| 亚洲图片欧美一区| 国产精品久久久久久久7电影| 亚洲午夜精品久久久久久浪潮| 99精品福利视频| 国产精品国产亚洲精品看不卡15| 亚洲婷婷国产精品电影人久久| 99国产精品国产精品毛片| 欧美久久一级|