mysql文件怎么上鎖 mysql常見鎖

MySQL數(shù)據(jù)庫表鎖定的幾種方法實現(xiàn)

如果兩個程序都向表中寫數(shù)據(jù)顯然會造成很大的麻煩,甚至會有意外情況發(fā)生。如果表正由一個程序?qū)懭?,同時進行讀取的另一個程序也會產(chǎn)生混亂的結(jié)果。

為大安等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù),及大安網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都做網(wǎng)站、網(wǎng)站制作、大安網(wǎng)站設(shè)計,以傳統(tǒng)方式定制建設(shè)網(wǎng)站,并提供域名空間備案等一條龍服務(wù),秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求,就會得到認可,從而選擇與我們長期合作。這樣,我們也可以走得更遠!

鎖定表的方法

防止客戶機的請求互相干擾或者服務(wù)器與維護程序相互干擾的方法主要有多種。如果你關(guān)閉數(shù)據(jù)庫,就可以保證服務(wù)器

和myisamchk和isamchk之間沒有交互作用。但是停止服務(wù)器的運行并不是一個好注意,因為這樣做會使得沒有故障的數(shù)據(jù)庫和表也不可用。本節(jié)主

要討論的過程,是避免服務(wù)器和myisamchk或isamchk之間的交互作用。實現(xiàn)這種功能的方法是對表進行鎖定。

服務(wù)器由兩種表的鎖定方法:

1.內(nèi)部鎖定

內(nèi)部鎖定可以避免客戶機的請求相互干擾——例如,避免客戶機的SELECT查詢被另一個客戶機的UPDATE查詢所干擾。也可以利用內(nèi)部鎖定機制防止服務(wù)器在利用myisamchk或isamchk檢查或修復表時對表的訪問。

語法:鎖定表:LOCK TABLES

tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},…]

解鎖表:UNLOCKTABLESLOCKTABLES為當前線程鎖定表。UNLOCK TABLES釋放被當前線程持有的任何鎖。當線程發(fā)出另外一個LOCK

TABLES時,或當服務(wù)器的連接被關(guān)閉時,當前線程鎖定的所有表自動被解鎖。

如果一個線程獲得在一個表上的一個READ鎖,該線程(和所有其他線程)只能從表中讀。如果一個線程獲得一個表上的一個WRITE鎖,那么只有持鎖的線程READ或WRITE表,其他線程被阻止。

每個線程等待(沒有超時)直到它獲得它請求的所有鎖。

WRITE鎖通常比READ鎖有更高的優(yōu)先級,以確保更改盡快被處理。這意味著,如果一個線程獲得READ鎖,并且然后另外一個線程請求一個WRITE鎖,

隨后的READ鎖請求將等待直到WRITE線程得到了鎖并且釋放了它。

顯然對于檢查,你只需要獲得讀鎖。再者鐘情跨下,只能讀取表,但不能修改它,因此他也允許其它客戶機讀取表。對于修復,你必須獲得些所以防止任何客戶機在你對表進行操作時修改它。

2.外部鎖定

服務(wù)器還可以使用外部鎖定(文件級鎖)來防止其它程序在服務(wù)器使用表時修改文件。通常,在表的檢查操作中服務(wù)器

將外部鎖定與myisamchk或isamchk作合使用。但是,外部鎖定在某些系統(tǒng)中是禁用的,因為他不能可靠的進行工作。對運行myisamchk或

isamchk所選擇的過程取決于服務(wù)器是否能使用外部鎖定。如果不使用,則必修使用內(nèi)部鎖定協(xié)議。

如果服務(wù)器用--skip-locking選項運行,則外部鎖定禁用。該選項在某些系統(tǒng)中是缺省的,如Linux??梢酝ㄟ^運行mysqladmin

variables命令確定服務(wù)器是否能夠使用外部鎖定。檢查skip_locking變量的值并按以下方法進行:

如果skip_locking為off,則外部鎖定有效您可以繼續(xù)并運行人和一個實用程序來檢查表。服務(wù)器和實用程序?qū)⒑献鲗Ρ磉M行訪問。但是,運行任何

一個實用程序之前,應(yīng)該使用mysqladmin flush-tables。為了修復表,應(yīng)該使用表的修復鎖定協(xié)議。

如果skip_locaking為on,則禁用外部鎖定,所以在myisamchk或isamchk檢查修復表示服務(wù)器并不知道,最好關(guān)閉服務(wù)器。如果堅

持是服務(wù)器保持開啟狀態(tài),月確保在您使用此表示沒有客戶機來訪問它。

mysql讀數(shù)據(jù)時怎么加寫鎖

加鎖情況與死鎖原因分析

為方便大家復現(xiàn),完整表結(jié)構(gòu)和數(shù)據(jù)如下:

CREATE TABLE `t3` (

`c1` int(11) NOT NULL AUTO_INCREMENT,

`c2` int(11) DEFAULT NULL,

PRIMARY KEY (`c1`),

UNIQUE KEY `c2` (`c2`)

) ENGINE=InnoDB

insert into t3 values(1,1),(15,15),(20,20);

在 session1 執(zhí)行 commit 的瞬間,我們會看到 session2、session3 的其中一個報死鎖。這個死鎖是這樣產(chǎn)生的:

1.?session1 執(zhí)行 delete ?會在唯一索引 c2 的 c2 = 15 這一記錄上加 X lock(也就是在MySQL 內(nèi)部觀測到的:X Lock but not gap);

2.?session2 和 session3 在執(zhí)行 insert 的時候,由于唯一約束檢測發(fā)生唯一沖突,會加 S Next-Key Lock,即對 (1,15] 這個區(qū)間加鎖包括間隙,并且被 seesion1 的 X Lock 阻塞,進入等待;

3.?session1 在執(zhí)行 commit 后,會釋放 X Lock,session2 和 session3 都獲得 S Next-Key Lock;

4.?session2 和 session3 繼續(xù)執(zhí)行插入操作,這個時候 INSERT INTENTION LOCK(插入意向鎖)出現(xiàn)了,并且由于插入意向鎖會被 gap 鎖阻塞,所以 session2 和 session3 互相等待,造成死鎖。

死鎖日志如下:

請點擊輸入圖片描述

INSERT INTENTION LOCK

在之前的死鎖分析第四點,如果不分析插入意向鎖,也是會造成死鎖的,因為插入最終還是要對記錄加 X Lock 的,session2 和 session3 還是會互相阻塞互相等待。

但是插入意向鎖是客觀存在的,我們可以在官方手冊中查到,不可忽略:

Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.

插入意向鎖其實是一種特殊的 gap lock,但是它不會阻塞其他鎖。假設(shè)存在值為 4 和 7 的索引記錄,嘗試插入值 5 和 6 的兩個事務(wù)在獲取插入行上的排它鎖之前使用插入意向鎖鎖定間隙,即在(4,7)上加 gap lock,但是這兩個事務(wù)不會互相沖突等待。

當插入一條記錄時,會去檢查當前插入位置的下一條記錄上是否存在鎖對象,如果下一條記錄上存在鎖對象,就需要判斷該鎖對象是否鎖住了 gap。如果 gap 被鎖住了,則插入意向鎖與之沖突,進入等待狀態(tài)(插入意向鎖之間并不互斥)。總結(jié)一下這把鎖的屬性:

1. 它不會阻塞其他任何鎖;

2. 它本身僅會被 gap lock 阻塞。

在學習 MySQL 過程中,一般只有在它被阻塞的時候才能觀察到,所以這也是它常常被忽略的原因吧...

GAP LOCK

在此例中,另外一個重要的點就是 gap lock,通常情況下我們說到 gap lock 都只會聯(lián)想到 REPEATABLE-READ 隔離級別利用其解決幻讀。但實際上在 READ-COMMITTED 隔離級別,也會存在 gap lock ,只發(fā)生在:唯一約束檢查到有唯一沖突的時候,會加 S Next-key Lock,即對記錄以及與和上一條記錄之間的間隙加共享鎖。

通過下面這個例子就能驗證:

請點擊輸入圖片描述

這里 session1 插入數(shù)據(jù)遇到唯一沖突,雖然報錯,但是對 (15,20] 加的 S Next-Key Lock 并不會馬上釋放,所以 session2 被阻塞。另外一種情況就是本文開始的例子,當 session2 插入遇到唯一沖突但是因為被 X Lock 阻塞,并不會立刻報錯 “Duplicate key”,但是依然要等待獲取 S Next-Key Lock 。

有個困惑很久的疑問:出現(xiàn)唯一沖突需要加 S Next-Key Lock 是事實,但是加鎖的意義是什么?還是說是通過 S Next-Key Lock 來實現(xiàn)的唯一約束檢查,但是這樣意味著在插入沒有遇到唯一沖突的時候,這個鎖會立刻釋放,這不符合二階段鎖原則。這點希望能與大家一起討論得到好的解釋。

如果是在 REPEATABLE-READ,除以上所說的唯一約束沖突外,gap lock 的存在是這樣的:

普通索引(非唯一索引)的S/X Lock,都帶 gap 屬性,會鎖住記錄以及前1條記錄到后1條記錄的左閉右開區(qū)間,比如有[4,6,8]記錄,delete 6,則會鎖住[4,8)整個區(qū)間。

對于 gap lock,相信 DBA 們的心情是一樣一樣的,所以我的建議是:

1. 在絕大部分的業(yè)務(wù)場景下,都可以把 MySQL 的隔離界別設(shè)置為 READ-COMMITTED;

2. 在業(yè)務(wù)方便控制字段值唯一的情況下,盡量減少表中唯一索引的數(shù)量。

鎖沖突矩陣

前面我們說的 GAP LOCK 其實是鎖的屬性,另外我們知道 InnoDB 常規(guī)鎖模式有:S 和 X,即共享鎖和排他鎖。鎖模式和鎖屬性是可以隨意組合的,組合之后的沖突矩陣如下,這對我們分析死鎖很有幫助:

請點擊輸入圖片描述

mysql默認隔離級別怎么加鎖

修改方法

有兩種方法可以對配置了 systemd 的程序進行資源隔離:1. 命令行修改:通過執(zhí)行?systemctl set-property?命令實現(xiàn),形式為?systemctl set-property?name parameter=value;修改默認即時生效。2. 手工修改文件:直接編輯程序的 systemd unit file 文件,完成之后需手工執(zhí)行?systemctl?daemon-reload?更新配置,并重啟服務(wù)?systemctl restart name.service。

systemd unit file 里支持的資源隔離配置項,如常見的:

CPUQuota=value

該參數(shù)表示服務(wù)可以獲取的最大 CPU 時間,value 為百分數(shù)形式,高于 100% 表示可使用?1 核以上的?CPU。與 cgroup cpu 控制器?cpu.cfs_quota_us?配置項對應(yīng)。

MemoryLimit=value

該參數(shù)表示服務(wù)可以使用的最大內(nèi)存量,value 可以使用 K, M, G, T 等后綴表示值的大小。與 cgroup?memory 控制器?memory.limit_in_bytes?配置項對應(yīng)。

事務(wù)的4種隔離級別

READ UNCOMMITTED ? ? ? 未提交讀,可以讀取未提交的數(shù)據(jù)。

READ COMMITTED ? ? ? ? 已提交讀,對于鎖定讀(select with for update 或者 for share)、update 和 delete 語句,InnoDB 僅鎖定索引記錄,而不鎖定它們之間的間隙,因此允許在鎖定的記錄旁邊自由插入新記錄。 ? ? ? ? ? ? ? ? ? ?

Gap locking 僅用于外鍵約束檢查和重復鍵檢查。

REPEATABLE READ ? ? ? ?可重復讀,事務(wù)中的一致性讀取讀取的是事務(wù)第一次讀取所建立的快照。

SERIALIZABLE ? ? ? ? ? 序列化在了解了 4 種隔離級別的需求后,在采用鎖控制隔離級別的基礎(chǔ)上,我們需要了解加鎖的對象(數(shù)據(jù)本身間隙),以及了解整個數(shù)據(jù)范圍的全集組成。

數(shù)據(jù)范圍全集組成

SQL 語句根據(jù)條件判斷不需要掃描的數(shù)據(jù)范圍(不加鎖);

SQL 語句根據(jù)條件掃描到的可能需要加鎖的數(shù)據(jù)范圍;

以單個數(shù)據(jù)范圍為例,數(shù)據(jù)范圍全集包含:(數(shù)據(jù)范圍不一定是連續(xù)的值,也可能是間隔的值組成)

分享文章:mysql文件怎么上鎖 mysql常見鎖
本文網(wǎng)址:http://muchs.cn/article34/hhsppe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供建站公司網(wǎng)站改版、網(wǎng)站策劃、網(wǎng)站制作、營銷型網(wǎng)站建設(shè)、Google

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

營銷型網(wǎng)站建設(shè)