## 用途
多個查詢需要在同一時刻修改數據,會產生并發控制的問題。使用鎖可以有效解決這個問題
## 鎖的分類
按照鎖的粒度劃分:行鎖、表鎖、頁鎖
按照鎖的使用方式劃分:共享鎖、排它鎖(悲觀鎖的一種實現)
還有兩種思想上的鎖:悲觀鎖、樂觀鎖
InnoDB中有幾種行級鎖類型:Record Lock(在索引記錄上加鎖)、Gap Lock(間隙鎖)、Next-key Lock(臨鍵鎖)
## 行鎖
? 行級鎖是Mysql中鎖定粒度最細的一種鎖,表示只針對當前操作的行進行加鎖。**行級鎖能大大減少數據庫操作的沖突。其加鎖粒度最小,但加鎖的開銷也最大。有可能會出現死鎖的情況。**行級鎖按照使用方式分為共享鎖和排他鎖。
* 共享鎖:同一時刻可以同時讀取同一個資源
* 排他鎖:一個寫鎖會阻塞其他的寫鎖和讀鎖
### 共享鎖用法(S鎖 讀鎖)
? 若事務T對數據對象A加上S鎖,則事務T可以讀A但不能修改A,其他事務只能再對A加S鎖,而不能加X鎖,直到T釋放A上的S鎖。這保證了其他事務可以讀A,但在T釋放A上的S鎖之前不能對A做任何修改。
select ... lock in share mode;
共享鎖就是允許多個線程同時獲取一個鎖,一個鎖可以同時被多個線程擁有。
### 排它鎖用法(X 鎖 寫鎖)
? 若事務T對數據對象A加上X鎖,事務T可以讀A也可以修改A,其他事務不能再對A加任何鎖,直到T釋放A上的鎖。這保證了其他事務在T釋放A上的鎖之前不能再讀取和修改A。
select ... for update
? 排它鎖,也稱作獨占鎖,一個鎖在某一時刻只能被一個線程占有,其它線程必須等待鎖被釋放之后才可能獲取到鎖。
## 表鎖
? 表級鎖是mysql鎖中粒度最大的一種鎖,表示當前的操作對整張表加鎖,資源開銷比行鎖少,不會出現死鎖的情況,但是發生鎖沖突的概率很大。被大部分的mysql引擎支持,MyISAM和InnoDB都支持表級鎖,但是InnoDB默認的是行級鎖。
共享鎖用法:
LOCK TABLE table_name [ AS alias_name ] READ
排它鎖用法:
LOCK TABLE table_name [AS alias_name][ LOW_PRIORITY ] WRITE
解鎖用法:
unlock tables;
## 頁鎖
? 頁級鎖是MySQL中鎖定粒度介于行級鎖和表級鎖中間的一種鎖。表級鎖速度快,但沖突多,行級沖突少,但速度慢。所以取了折衷的頁級,一次鎖定相鄰的一組記錄。BDB支持頁級鎖
。
## 悲觀鎖和樂觀鎖
無論是悲觀鎖還是樂觀鎖,都是人們定義出來的概念,可以認為是一種思想。其實不僅僅是數據庫系統中有樂觀鎖和悲觀鎖的概念,像memcache、hibernate、tair等都有類似的概念。
針對于不同的業務場景,應該選用不同的并發控制方式。所以,不要把樂觀并發控制和悲觀并發控制狹義的理解為DBMS中的概念,更不要把他們和數據中提供的鎖機制(行鎖、表鎖、排他鎖、共享鎖)混為一談。其實,在DBMS中,悲觀鎖正是利用數據庫本身提供的鎖機制來實現的。
### MySQL InnoDB中使用悲觀鎖
要使用悲觀鎖,我們必須關閉mysql數據庫的自動提交屬性,因為MySQL默認使用autocommit模式,也就是說,當你執行一個更新操作后,MySQL會立刻將結果進行提交。 set autocommit=0;
~~~
//0.開始事務
begin;/begin work;/start transaction; (三者選一就可以)
//1.查詢出商品信息
select status from t_goods where id=1 for update;
//2.根據商品信息生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status為2
update t_goods set status=2;
//4.提交事務
commit;
~~~
上面的查詢語句中,我們使用了 select…for update 的方式,這樣就通過開啟排他鎖的方式實現了悲觀鎖。此時在t_goods表中,id為1的 那條數據就被我們鎖定了,其它的事務必須等本次事務提交之后才能執行。這樣我們可以保證當前的數據不會被其它事務修改。
上面我們提到,使用 select…for update 會把數據給鎖住,不過我們需要注意一些鎖的級別,MySQL InnoDB默認行級鎖。行級鎖都是基于索引的,如果一條SQL語句用不到索引是不會使用行級鎖的,會使用表級鎖把整張表鎖住,這點需要注意。
### 優點與不足
悲觀并發控制實際上是“先取鎖再訪問”的保守策略,為數據處理的安全提供了保證。但是在效率方面,處理加鎖的機制會讓數據庫產生額外的開銷,還有增加產生死鎖的機會;另外,在只讀型事務處理中由于不會產生沖突,也沒必要使用鎖,這樣做只能增加系統負載;還有會降低了并行性,一個事務如果鎖定了某行數據,其他事務就必須等待該事務處理完才可以處理那行數。
## 樂觀鎖
在關系數據庫管理系統里,樂觀并發控制(又名“樂觀鎖”,Optimistic Concurrency Control,縮寫“OCC”)是一種并發控制的方法。它假設多用戶并發的事務在處理時不會彼此互相影響,各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前,每個事務會先檢查在該事務讀取數據后,有沒有其他事務又修改了該數據。如果其他事務有更新的話,正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重(H.T.Kung)教授提出。
樂觀鎖( Optimistic Locking ) 相對悲觀鎖而言,樂觀鎖假設認為數據一般情況下不會造成沖突,所以在數據進行提交更新的時候,才會正式對數據的沖突與否進行檢測,如果發現沖突了,則讓返回用戶錯誤的信息,讓用戶決定如何去做。
相對于悲觀鎖,在對數據庫進行處理的時候,樂觀鎖并不會使用數據庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄數據版本。
數據版本,為數據增加的一個版本標識。當讀取數據時,將版本標識的值一同讀出,數據每更新一次,同時對版本標識進行更新。當我們提交更新的時候,判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對,如果數據庫表當前版本號與第一次取出來的版本標識值相等,則予以更新,否則認為是過期數據。
實現數據版本有兩種方式,第一種是使用版本號,第二種是使用時間戳,方法類似,下面舉例說明版本號的做法。
### 使用版本號實現樂觀鎖
使用數據版本(Version)記錄機制實現,這是樂觀鎖最常用的一種實現方式。何謂數據版本?即為數據增加一個版本標識,一般是通過為數據庫表增加一個數字類型的 “version” 字段來實現。當讀取數據時,將version字段的值一同讀出,數據每更新一次,對此version值加一。當我們提交更新的時候,判斷數據庫表對應記錄的當前版本信息與第一次取出來的version值進行比對,如果數據庫表當前版本號與第一次取出來的version值相等,則予以更新,否則認為是過期數據
#### 1.數據庫表設計
task表有三個字段,分別是id,value,version
#### 2.實現
1)先讀task表的數據(實際上這個表只有一條記錄),得到version的值為versionValue
2)每次更新task表中的value字段時,為了防止發生沖突,需要這樣操作
~~~
update task set value = newValue,version = versionValue + 1 where version = versionValue;
~~~
只有這條語句執行了,才表明本次更新value字段的值成功
如假設有兩個節點A和B都要更新task表中的value字段值,差不多在同一時刻,A節點和B節點從task表中讀到的version值為2,那么A節點和B節點在更新value字段值的時候,都操作 update task set value = newValue,version = 3 where version = 2;,實際上只有1個節點執行該SQL語句成功,假設A節點執行成功,那么此時task表的version字段的值是3,B節點再操作update task set value = newValue,version = 3 where version = 2;這條SQL語句是不執行的,這樣就保證了更新task表時不發生沖突。
## 鎖粒度
* 表鎖:開銷最小,對表進行寫操作,需要獲得寫鎖,會阻塞該表的所有讀寫操作
* 行級鎖:最大鎖開銷,可以最大程度地支持并發處理
# 行鎖與表鎖的轉變
InnoDB 行級鎖是通過給索引上的索引項加鎖來實現的,InnoDB行級鎖只有通過索引條件檢索數據,才使用行級鎖;否則,InnoDB使用表鎖
在不通過索引(主鍵)條件查詢的時候,InnoDB是表鎖而不是行鎖。也就是說,在沒有使用索引的情況下,使用的就是表鎖。
## 間隙鎖
間隙鎖可以理解為是對于一定范圍內的數據進行鎖定,如果說這個區間沒有這條數據的話也是會鎖住的;主要是解決幻讀的問題,如果沒有添加間隙鎖,如果其他事物中添加id在1到100之間的某條記錄,此時會發生幻讀;另一方面,視為了滿足其恢復和賦值的需求(幻讀的概念在事務隔離文章中有提到)。
默認情況下,innodb_locks_unsafe_for_binlog是0(禁用),這意味著啟用了間隙鎖定:InnoDB使用下一個鍵鎖進行搜索和索引掃描。若要啟用該變量,請將其設置為1。這將導致禁用間隙鎖定:InnoDB只使用索引記錄鎖進行搜索和索引掃描。
### innodb自動使用間隙鎖的條件:
必須在RR級別下
檢索條件必須有索引(沒有索引的話,mysql會全表掃描,那樣會鎖定整張表所有的記錄,包括不存在的記錄,此時其他事務不能修改不能刪除不能添加)
### 間隙鎖的目的是為了防止幻讀,其主要通過兩個方面實現這個目的:
防止間隙內有新數據被插入
防止已存在的數據,更新成間隙內的數據(例如防止numer=3的記錄通過update變成number=5)
下面將通過例子來詳細了解一下間隙鎖的出現場景:
create table y (
id int primary key ,
num int
);
其中id為主鍵索引,a為二級索引。
數據如下:
id num
1 2
3 4
5 5
7 5
9 8
場景:

間隙區間:從查找的字段向上和向下去找。
通過上面的場景,我們可以先找到間隙區間(2,4)(4,5),因此我們可以確定 id 在 1-3,3-5之間,也就是為id為2,4的記錄,number在上述間隙區間的值不能夠插入。
## 死鎖
## 為什么會產生死鎖
兩個事務都持有對方需要的鎖,并且在等待對方釋放,并且雙方都不會釋放自己的鎖。
### 出現死鎖的原因
1. 系統資源不足
2. 進程運行推進的順序不當
3. 資源分配不當
### 產生死鎖的四個必要條件
1. 互斥條件: 一個資源只能被一個進程使用
2. 請求和保持條件:進行獲得一定資源,又對其他資源發起了請求,但是其他資源被其他線程占用,請求阻塞,但是也不會釋放自己占用的資源。
3. 不可剝奪條件: 指進程所獲得的資源,不可能被其他進程剝奪,只能自己釋放
4. 環路等待條件: 進程發生死鎖,必然存在著進程-資源之間的環形鏈
### 處理死鎖的方法
預防,避免,檢查,解除死鎖
### 減少死鎖的方法
使用事務,不使用 lock tables 。
保證沒有長事務。
操作完之后立即提交事務,特別是在交互式命令行中。
如果在用 (SELECT … FOR UPDATE or SELECT … LOCK IN SHARE
MODE),嘗試降低隔離級別。
修改多個表或者多個行的時候,將修改的順序保持一致。
創建索引,可以使創建的鎖更少。
最好不要用 (SELECT … FOR UPDATE or SELECT … LOCK IN SHARE MODE)。
如果上述都無法解決問題,那么嘗試使用 lock tables t1, t2, t3 鎖多張表
### 可以參考
[數據庫中的事務和鎖](https://blog.csdn.net/woshiluoye9/article/details/68954515)
- 前言
- 讀者須知
- 第一章 Linux
- HTTP
- 簡介
- 狀態碼
- 特點
- URL
- Request
- Response
- 請求方式
- 工作原理
- 生命周期
- GET和POST區別
- 組成
- 端口
- 命令
- 常用命令
- chmod命令詳解
- ubuntu apt-get命令
- 用戶和用戶組
- Nginx
- 四個基本功能
- 進程
- 進程管理[ps命令]
- 進程管理[top命令]
- 進程管理[kill命令]
- 進程管理[進程優先級]
- 進程管理[netstat命令]
- 定時任務
- crontab
- 實現每秒執行
- >/dev/null 2>&1說明
- 文件管理
- 工作管理
- 資源管理
- 第二章 NGINX
- 介紹
- 入門
- 特性
- 安裝啟動
- 基礎必會
- 常用功能
- 反向代理
- 負載均衡
- 正向代理
- HTTP服務器
- 動靜分離
- 技能點匯總
- 顯示亂碼
- 打開目錄瀏覽功能
- 錯誤碼原因和解決方案
- location用法
- 常用正則
- rewrite
- 全局變量
- if語句塊
- https
- php后端處理(fast-cgi)
- flag標志位
- 過期功能
- gzip壓縮
- 會話保持時間
- 配置nginx worker進程最大打開文件數
- sendfile
- 單個工作進程的最大連接數
- 選擇事件驅動模型
- 隱藏ngxin版本號
- 網絡連接的優化
- 緩存原理及機制
- 限流
- 日志配置
- 灰度發布
- 配置一鍵生成
- 第三章 MySQL
- 入門
- 簡介
- 術語
- 特點
- 三范式
- 8.0 新特性
- 數據類型
- 數據類型詳解
- 常用函數
- 命令速查
- MyISAM與InnoDB區別
- 服務器構成
- 事務
- 本質
- 特性
- 分類
- 隔離級別
- PHP中使用事務實例
- MVCC
- 問題和解決
- 調優原則
- 分布式事務
- 索引
- 簡介
- 索引的分類
- 創建索引
- 刪除索引
- 哈希索引
- btree索引和hash索引的區別
- 單列索引和多列索引
- 索引優化
- 查看SQL語句對索引的使用情況
- 鎖
- 技能點
- 開發規范
- 導入導出數據庫
- blob和text的區別
- char與varchar類型區別
- SQL查詢語句優化
- 事務隔離和鎖操作需要在語言級別來做嗎
- 58到家數據庫30條軍規解讀
- 數據遷移
- SKU數據庫設計
- RBAC數據庫設計
- 第四章 Redis
- 入門
- 簡介
- 應用場景
- 安裝啟動
- 生命周期
- 事務
- 配置項
- 緩存
- 數據持久化
- 安全
- 數據類型
- string
- hash
- list
- set
- zset
- php代碼實戰
- 字符串緩存實戰
- 隊列實戰
- 發布訂閱實戰
- 計數器實戰
- 排行榜實戰
- 字符串悲觀鎖實戰
- 事務的樂觀鎖實戰
- 高級應用
- 分片機制
- 主從復制
- 緩存問題
- 解決 Redis 并發競爭 Key 問題
- 淘汰策略
- 第五章 PHP
- composer
- 什么是composer
- composer常用概念解析
- 使用composer的正確姿勢
- 消息隊列
- 為何使用消息隊列
- Beanstalkd
- PSR規范
- PSR-0
- PSR-1
- PSR-2
- PSR-3
- PSR-4
- OOP基礎
- 面向對象概念
- 類和對象
- 類
- 操作對象成員
- this使用
- 構造方法和析構方法
- 封裝
- __set(),__get(),__isset(),__unset()四個方法的應用
- 繼承
- 重載新的方法(parent::)
- 訪問類型(public,protected,private)
- final關鍵字的應用
- static和const關鍵字的使用(self::)
- static關鍵字
- __toString()方法
- 克隆對象__clone()方法
- __call()處理調用錯誤
- 抽象方法和抽象類(abstract)
- 接口(interface)
- 多態
- 把對象串行化serialize()方法,__sleep()方法,__wakeup()方法
- 自動加載類 __autoload()函數
- OOP進階
- 語法糖
- 異常處理
- 后期靜態綁定
- 后期靜態綁定在框架的運用
- 代碼優化思路
- Closure(閉包)
- 巧用PHP內置方法
- 數組操作的奇技淫巧
- 設計模式
- 單例模式(Singleton Pattern)
- 工廠模式(Factor Pattern)
- 建造者模式(Builder Pattern)
- 原型模式(Prototype Pattern)
- 適配器模式(Adapter Pattern)
- 裝飾器模式(Decorator Pattern)
- 代理模式(Proxy Pattern)
- 外觀模式(Facade Pattern)
- 橋接模式(Bridge Pattern)
- 組合模式(Composite Pattern)
- 享元模式 (Flyweight Pattern)
- 策略模式 ( Strategy Pattern )
- 模板模式 (Template Pattern)
- 觀察者模式 (observer Pattern)
- 迭代模式(Iterator Pattern)
- 責任鏈模式(Chain of Responsibility Pattern)
- 命令模式 (Command Pattern)
- 備忘錄模式(Memento Pattern)
- 狀態模式 (State Pattern)
- 訪問者模式(Visitor Pattern)
- 中介者模式(Mediator Pattern)
- 解釋器模式(Interpreter Pattern)
- 數據映射模式(Data Mapper Pattern)
- 注冊樹模式(Registry Pattern)
- 空對象模式(Null Object Pattern)
- 搜索引擎
- Elasticsearch
- 安裝
- 入門
- 實踐
- 集群
- 查詢
- API
- 接口調用
- cURL
- Guzzle
- RPC
- yar
- session
- 概念
- 客戶端實現形式
- cookie與session的區別
- Cookies的安全性
- JWT
- 組成
- 入門
- 應用
- 知識點
- 常見
- $_SERVER
- php的引用
- 第六章 技術棧擴展
- 使用第三方靜態資源服務
- 七牛對象存儲實戰
- 七牛對象存儲之客戶端上傳
- aliyunOSS服務端文件上傳
- aliyunOSS客戶端文件上傳
- 第三方支付
- 微信支付
- 支付寶支付
- SEO排名影響因素
- PHP架構師之路
- CTO職能
- web宏觀分析
- 常見的企業軟件系統
- 負載的優化思路
- 從容應對負載并發的前期準備
- 第七章 網絡安全
- XSS
- CSRF
- DDoS
- SQL注入
- 停用js
- 文件上傳
- 點擊劫持
- APT
- 會話劫持
- 第八章 運維
- devops
- devops簡介
- 常用工具
- 搭建運行環境
- Centos7 lnmp環境搭建
- ubuntu lnmp環境搭建
- Apache多站點配置
- docker
- 輕松使用和理解docker
- lnamp產品級環境搭建
- lnamp產品級環境搭建【第二版】
- 基于 Docker 容器的沙盒化評測系統
- vagrant
- vagrant入門
- vagrant之Vagrantfile
- vagrant之集成jenkins
- homestead
- gitlab
- gitlab簡介
- webhook
- ssh堡壘機
- 第九章 測試
- 壓力測試
- 單元測試
- 第十章 團隊協作
- 軟件開發模式
- 邊做邊改模型
- 瀑布模型
- 迭代模型
- 快速原型模型
- 增量模型
- 螺旋模型
- 敏捷軟件開發
- 演化模型
- 噴泉模型
- 智能模型
- 混合模型
- 模型對比
- TDD
- git
- git_入門
- git_使用
- git_進階
- git workflow
- git_高級
- git_小技巧
- okr工作法
- API接口文檔管理系統
- 敏捷協作工具
- 第十一章 技術燈塔
- github項目
- 社區好貨
- 紙質書
- 第十二章 代碼之外
- 面試官的角度看面試
- 程序員的壯年思考