前言
鎖總體可以分為樂觀鎖和悲觀鎖，簡單說，樂觀鎖用版本號控制，悲觀鎖用鎖控制。
下面是待會要用來測試的資料12
3456
78910
1112
# 新增乙個user表
create table `users` (
`id` int(11) not null auto_increment comment 'id',
`name` varchar(255) not null comment '姓名',
primary key (`id`)
) engine=innodb auto_increment=2 default charset=utf8;
# 插入3條資料
insert into `users` (`id`, `name`)
values
(1, '雪山飛豬'),
(2, 'chenqionghe'),
(3, 'cqh');
查詢結果如下：
一、樂觀鎖
核心原理是增加乙個version的字段來控制。
舉個場景，我們希望併發更新單行記錄的時候的時候，只有乙個程序更新成功，如下12
update users set name="雪山飛豬" where id=3
update users set name="chenqionghe" where id=3
上面這兩個sql最終都會更新成功，且以最後更新結果為主。
解決辦法是新增乙個version欄位
新增version欄位
1alter table users add `version` int not null default '0'
解決辦法是新增乙個version欄位，每個更新時where條件都加上它，並且也更新它12
update users set name="雪山飛豬",version=version+1 where id=3 and version=0
update users set name="chenqionghe",version=version+1 where id=3 and version=0
這次變成了只會更新成功一次，誰先搶到這條記錄以誰為主，因為當前乙個程序更新成功後版本號已經變化了，第二個程序找不到這條記錄了。
這就是最簡單的cas機制。
二、悲觀鎖
其實類似go語言裡的mutex和rwmutex讀鎖
讀鎖也叫共享鎖或s鎖，當給資料表加上共享鎖的時候，表就變成了唯讀模式。
我們可以鎖全表，也可以鎖全表或部分行，如下
全表鎖（lock table 表 read）
語法如下12
lock table 表 read
unlock table;
我們來測試乙個，第乙個程序執行
1lock table users read;
第二個程序執行正常讀
1select * from users where id=1;
可以正常查詢。我們再來執行一下更新
1update users set name="chenqionghe" where id=1
出現了等待。
我們給第乙個程序解鎖
再看第二個程序，已經更新成功
行鎖（select ... lock in share mode）12
3begin;
select * from users where id in (1,2) lock in share mode
commit;
必須配合事務使用，bein開始後，鎖定的行，外部只能查詢，不能更新
我們來測試一下，第乙個程序執行12
begin;
select * from users where id in (1,2) lock in share mode
這裡鎖定了id為1和2的記錄行。我們第二個程序執行更新
1update users set name="雪山飛豬" where id=1
又一次出現了等待。
好，這時候我們將第乙個程序的事務提交
1commit;
第二個程序更新成功了，如下
寫鎖也排他鎖、獨佔鎖，理解成讀和寫都不行了，語法如下
全表鎖（lock table 表 write）
1lock table users write;
這時候已經鎖定全表，我們再用另乙個程序查詢一下id為1的資料
1select * from users where id=1
可以看到，查詢已經發生了等待。
我們再將第乙個程序解鎖
1unlock table
這時候，第二個程序立馬查詢成功
行鎖（select ... for update）
當我們對資料進行更新的時候（insert、delete、update）的時候，資料庫會自動使用排它鎖，防止其他事務操作該資料12
3begin;
select * from users where id in (1,2) lock in share mode
commit;
我們再來測試一下，第乙個程序鎖定id為1和2的記錄12
begin;
select * from users where id in (1,2) for update
注意：這時候事務沒提交
我們先用第二個程序來更新id為3的記錄（未被鎖定）
1update users set name="chenqionghe" where id=3
執行成功了。
我們再來更新乙個id為1的記錄
1update users set name="chenqionghe" where id=1
發生了等待，說明已經被鎖定了。
好，我們提交第乙個程序的事務
1commit;
再去看第二個程序，已經更新成功
簡單說樂觀鎖用version控制，悲觀鎖的表鎖一般用不著，行的讀鎖用lock in share mode，寫鎖用fro update，就是這麼簡單！
事務併發 併發控制（加鎖）
事務處理中的併發控制 1.併發操作 資料庫是乙個共享資源，允許多個使用者程式並行地訪問資料庫，所以當多個使用者併發地訪問同一資料，就可能出現資料的不一致性。例如 假設有兩個事務 t1 和 t2 它們都需要讀出並修改資料 a 其執 況如下所示 執行順序 1 2 3 4 5 6 事務t1 讀aa a 1...
mysql 併發控制 mysql併發控制
mysql併發控制 當有多個查詢需要同時修改同乙個資料，就會產生併發控制的問題。mysql可以在兩個層面進行併發控制 伺服器層和儲存引擎層。mysql通過加鎖實現併發控制 鎖有兩類 讀鎖 共享鎖，即乙個讀鎖不會阻塞其它讀鎖，多個使用者可同時讀取同乙個資源，而不互相干擾。寫鎖 排他鎖，即乙個寫鎖會阻塞...
mysql 併發控制
1 多個執行緒同時修改資料，存在資料不一致的情況，也就是併發控制的問題。2 mysql提供讀鎖和寫鎖，讀鎖之上可以再加讀鎖，不能加寫鎖，而寫鎖之上不能加任何鎖。也就是說，讀鎖是共享的，寫鎖是排他的。3 鎖粒度，為了更好的併發控制，鎖的粒度應該盡可能小，也就是只鎖定修改的資料。但是，鎖本身也有一定的開...