MyISAM和InnoDB存儲(chǔ)引擎使用的鎖：
創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)敦化,十余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):18982081108
封鎖粒度?。?/p>
由于InnoDB存儲(chǔ)引擎支持的是行級(jí)別的鎖，因此意向鎖（因?yàn)橐庀蜴i是表鎖）其實(shí)不會(huì)阻塞除全表掃以外的任何請(qǐng)求。故表級(jí)意向鎖與行級(jí)鎖的兼容性如下所示
參考
參考
行鎖的三種算法：
這條語(yǔ)句阻止其他事務(wù)插入10和20之間的數(shù)字，無(wú)論這個(gè)數(shù)字是否存在。 間隙可以跨越0個(gè)，單個(gè)或多個(gè)索引值。
共享鎖：
排他鎖：
樂(lè)觀鎖：總是假設(shè)最好的情況，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改（天真）， 操作數(shù)據(jù)時(shí)不會(huì)上鎖 ，但是 更新時(shí)會(huì)判斷在此期間有沒有別的事務(wù)更新這個(gè)數(shù)據(jù)，若被更新過(guò)，則失敗重試 ；適用于讀多寫少的場(chǎng)景。
樂(lè)觀鎖的實(shí)現(xiàn)方式 有：
關(guān)閉自動(dòng)提交后，我們需要手動(dòng)開啟事務(wù)。
上述就實(shí)現(xiàn)了悲觀鎖，悲觀鎖就是悲觀主義者，它會(huì)認(rèn)為我們?cè)谑聞?wù)A中操作數(shù)據(jù)1的時(shí)候，一定會(huì)有事務(wù)B來(lái)修改數(shù)據(jù)1,所以，在第2步我們將數(shù)據(jù)查詢出來(lái)后直接加上排它鎖（X）鎖，防止別的事務(wù)來(lái)修改事務(wù)1，直到我們commit后，才釋放了排它鎖。
mysql鎖分為共享鎖和排他鎖，也叫做讀鎖和寫鎖。
讀鎖是共享的，可以通過(guò)lock in share mode實(shí)現(xiàn)，這時(shí)候只能讀不能寫。
寫鎖是排他的，它會(huì)阻塞其他的寫鎖和讀鎖。從顆粒度來(lái)區(qū)分，可以分為表鎖和?鎖兩種。
表鎖會(huì)鎖定整張表并且阻塞其他?戶對(duì)該表的所有讀寫操作，?如alter修改表結(jié)構(gòu)的時(shí)候會(huì)鎖表。
?鎖?可以分為樂(lè)觀鎖和悲觀鎖，悲觀鎖可以通過(guò)for update實(shí)現(xiàn)，樂(lè)觀鎖則通過(guò)版本號(hào)實(shí)現(xiàn)。
關(guān)于mysql中的樂(lè)觀鎖和悲觀鎖面試的時(shí)候被問(wèn)到的概率還是比較大的。
mysql的悲觀鎖：
其實(shí)理解起來(lái)非常簡(jiǎn)單，當(dāng)數(shù)據(jù)被外界修改持保守態(tài)度，包括自身系統(tǒng)當(dāng)前的其他事務(wù)，以及來(lái)自外部系統(tǒng)的事務(wù)處理，因此，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制，但是也只有數(shù)據(jù)庫(kù)層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問(wèn)的排他性，否則，即使在自身系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無(wú)法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)。
來(lái)點(diǎn)實(shí)際的，當(dāng)我們使用悲觀鎖的時(shí)候我們首先必須關(guān)閉mysql數(shù)據(jù)庫(kù)的自動(dòng)提交屬性，因?yàn)镸ySQL默認(rèn)使用autocommit模式，也就是說(shuō)，當(dāng)你執(zhí)行一個(gè)更新操作后，MySQL會(huì)立刻將結(jié)果進(jìn)行提交。
關(guān)閉命令為：set autocommit=0;
悲觀鎖可以使用select…for update實(shí)現(xiàn)，在執(zhí)行的時(shí)候會(huì)鎖定數(shù)據(jù)，雖然會(huì)鎖定數(shù)據(jù)，但是不影響其他事務(wù)的普通查詢使用。此處說(shuō)普通查詢就是平時(shí)我們用的：select * from table 語(yǔ)句。在我們使用悲觀鎖的時(shí)候事務(wù)中的語(yǔ)句例如：
//開始事務(wù)
begin;/begin work;/start transaction; (三選一)
//查詢信息
select * from order where id=1 for update;
//修改信息
update order set name='names';
//提交事務(wù)
commit;/commit work;(二選一)
此處的查詢語(yǔ)句for update關(guān)鍵字，在事務(wù)中只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一條數(shù)據(jù)時(shí)會(huì)等待其它事務(wù)結(jié)束后才執(zhí)行，一般的SELECT查詢則不受影響。
執(zhí)行事務(wù)時(shí)關(guān)鍵字select…for update會(huì)鎖定數(shù)據(jù)，防止其他事務(wù)更改數(shù)據(jù)。但是鎖定數(shù)據(jù)也是有規(guī)則的。
查詢條件與鎖定范圍：
1、具體的主鍵值為查詢條件
比如查詢條件為主鍵ID=1等等，如果此條數(shù)據(jù)存在，則鎖定當(dāng)前行數(shù)據(jù)，如果不存在，則不鎖定。
2、不具體的主鍵值為查詢條件
比如查詢條件為主鍵ID1等等，此時(shí)會(huì)鎖定整張數(shù)據(jù)表。
3、查詢條件中無(wú)主鍵
會(huì)鎖定整張數(shù)據(jù)表。
4、如果查詢條件中使用了索引為查詢條件
明確指定索引并且查到，則鎖定整條數(shù)據(jù)。如果找不到指定索引數(shù)據(jù)，則不加鎖。
悲觀鎖的確保了數(shù)據(jù)的安全性，在數(shù)據(jù)被操作的時(shí)候鎖定數(shù)據(jù)不被訪問(wèn)，但是這樣會(huì)帶來(lái)很大的性能問(wèn)題。因此悲觀鎖在實(shí)際開發(fā)中使用是相對(duì)比較少的。
mysql的樂(lè)觀鎖：
相對(duì)悲觀鎖而言，樂(lè)觀鎖假設(shè)數(shù)據(jù)一般情況下不會(huì)造成沖突，所以在數(shù)據(jù)進(jìn)行提交更新的時(shí)候，才會(huì)對(duì)數(shù)據(jù)的沖突與否進(jìn)行檢測(cè)，如果發(fā)現(xiàn)沖突，則讓返回用戶錯(cuò)誤的信息，讓用戶決定如何去做。
一般來(lái)說(shuō)，實(shí)現(xiàn)樂(lè)觀鎖的方法是在數(shù)據(jù)表中增加一個(gè)version字段，每當(dāng)數(shù)據(jù)更新的時(shí)候這個(gè)字段執(zhí)行加1操作。這樣當(dāng)數(shù)據(jù)更改的時(shí)候，另外一個(gè)事務(wù)訪問(wèn)此條數(shù)據(jù)進(jìn)行更改的話就會(huì)操作失敗，從而避免了并發(fā)操作錯(cuò)誤。當(dāng)然，還可以將version字段改為時(shí)間戳，不過(guò)原理都是一樣的。
例如有表student，字段：
id,name,version
1 a 1
當(dāng)事務(wù)一進(jìn)行更新操作：update student set name='ygz' where id = #{id} and version = #{version};
此時(shí)操作完后數(shù)據(jù)會(huì)變?yōu)閕d = 1,name = ygz,version = 2，當(dāng)另外一個(gè)事務(wù)二同樣執(zhí)行更新操作的時(shí)候，卻發(fā)現(xiàn)version != 1，此時(shí)事務(wù)二就會(huì)操作失敗，從而保證了數(shù)據(jù)的正確性。
悲觀鎖和樂(lè)觀鎖都是要根據(jù)具體業(yè)務(wù)來(lái)選擇使用，本文僅作簡(jiǎn)單介紹。
1、SQL語(yǔ)句執(zhí)行流程
MySQL大體上可分為Server層和存儲(chǔ)引擎層兩部分。
Server層：
連接器：TCP握手后服務(wù)器來(lái)驗(yàn)證登陸用戶身份，A用戶創(chuàng)建連接后，管理員對(duì)A用戶權(quán)限修改了也不會(huì)影響到已經(jīng)創(chuàng)建的鏈接權(quán)限，必須重新登陸。
查詢緩存：查詢后的結(jié)果存儲(chǔ)位置，MySQL8.0版本以后已經(jīng)取消，因?yàn)椴樵兙彺媸l繁，得不償失。
分析器：根據(jù)語(yǔ)法規(guī)則，判斷你輸入的這個(gè)SQL語(yǔ)句是否滿足MySQL語(yǔ)法。
優(yōu)化器：多種執(zhí)行策略可實(shí)現(xiàn)目標(biāo)，系統(tǒng)自動(dòng)選擇最優(yōu)進(jìn)行執(zhí)行。
執(zhí)行器：判斷是否有權(quán)限，將最終任務(wù)提交到存儲(chǔ)引擎。
存儲(chǔ)引擎層
負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和提取。其架構(gòu)模式是插件式的，支持InnoDB、MyISAM、Memory等多個(gè)存儲(chǔ)引擎?，F(xiàn)在最常用的存儲(chǔ)引擎是InnoDB，它從MySQL 5.5.5版本開始成為了默認(rèn)存儲(chǔ)引擎(經(jīng)常用的也是這個(gè))。
SQL執(zhí)行順序
2、BinLog、RedoLog、UndoLog
BinLog
BinLog是記錄所有數(shù)據(jù)庫(kù)表結(jié)構(gòu)變更（例如create、alter table）以及表數(shù)據(jù)修改(insert、update、delete)的二進(jìn)制日志，主從數(shù)據(jù)庫(kù)同步用到的都是BinLog文件。BinLog日志文件有三種模式。
STATEMENT 模式
內(nèi)容：binlog 記錄可能引起數(shù)據(jù)變更的 sql 語(yǔ)句
優(yōu)勢(shì)：該模式下，因?yàn)闆]有記錄實(shí)際的數(shù)據(jù)，所以日志量很少 IO 都消耗很低，性能是最優(yōu)的
劣勢(shì)：但有些操作并不是確定的，比如 uuid() 函數(shù)會(huì)隨機(jī)產(chǎn)生唯一標(biāo)識(shí)，當(dāng)依賴 binlog 回放時(shí)，該操作生成的數(shù)據(jù)與原數(shù)據(jù)必然是不同的，此時(shí)可能造成無(wú)法預(yù)料的后果。
ROW 模式
內(nèi)容：在該模式下，binlog 會(huì)記錄每次操作的源數(shù)據(jù)與修改后的目標(biāo)數(shù)據(jù)，StreamSets就要求該模式。
優(yōu)勢(shì)：可以絕對(duì)精準(zhǔn)的還原，從而保證了數(shù)據(jù)的安全與可靠，并且復(fù)制和數(shù)據(jù)恢復(fù)過(guò)程可以是并發(fā)進(jìn)行的
劣勢(shì)：缺點(diǎn)在于 binlog 體積會(huì)非常大，同時(shí)，對(duì)于修改記錄多、字段長(zhǎng)度大的操作來(lái)說(shuō)，記錄時(shí)性能消耗會(huì)很嚴(yán)重。閱讀的時(shí)候也需要特殊指令來(lái)進(jìn)行讀取數(shù)據(jù)。
MIXED 模式
內(nèi)容：是對(duì)上述STATEMENT 跟 ROW 兩種模式的混合使用。
細(xì)節(jié)：對(duì)于絕大部分操作，都是使用 STATEMENT 來(lái)進(jìn)行 binlog 沒有記錄，只有以下操作使用 ROW 來(lái)實(shí)現(xiàn)：表的存儲(chǔ)引擎為 NDB，使用了uuid() 等不確定函數(shù)，使用了 insert delay 語(yǔ)句，使用了臨時(shí)表
主從同步流程：
1、主節(jié)點(diǎn)必須啟用二進(jìn)制日志，記錄任何修改了數(shù)據(jù)庫(kù)數(shù)據(jù)的事件。
2、從節(jié)點(diǎn)開啟一個(gè)線程（I/O Thread)把自己扮演成 mysql 的客戶端，通過(guò) mysql 協(xié)議，請(qǐng)求主節(jié)點(diǎn)的二進(jìn)制日志文件中的事件 。
3、主節(jié)點(diǎn)啟動(dòng)一個(gè)線程（dump Thread），檢查自己二進(jìn)制日志中的事件，跟對(duì)方請(qǐng)求的位置對(duì)比，如果不帶請(qǐng)求位置參數(shù)，則主節(jié)點(diǎn)就會(huì)從第一個(gè)日志文件中的第一個(gè)事件一個(gè)一個(gè)發(fā)送給從節(jié)點(diǎn)。
4、從節(jié)點(diǎn)接收到主節(jié)點(diǎn)發(fā)送過(guò)來(lái)的數(shù)據(jù)把它放置到中繼日志（Relay log）文件中。并記錄該次請(qǐng)求到主節(jié)點(diǎn)的具體哪一個(gè)二進(jìn)制日志文件內(nèi)部的哪一個(gè)位置（主節(jié)點(diǎn)中的二進(jìn)制文件會(huì)有多個(gè)）。
5、從節(jié)點(diǎn)啟動(dòng)另外一個(gè)線程（sql Thread ），把 Relay log 中的事件讀取出來(lái)，并在本地再執(zhí)行一次。
mysql默認(rèn)的復(fù)制方式是異步的，并且復(fù)制的時(shí)候是有并行復(fù)制能力的。主庫(kù)把日志發(fā)送給從庫(kù)后不管了，這樣會(huì)產(chǎn)生一個(gè)問(wèn)題就是假設(shè)主庫(kù)掛了，從庫(kù)處理失敗了，這時(shí)候從庫(kù)升為主庫(kù)后，日志就丟失了。由此產(chǎn)生兩個(gè)概念。
全同步復(fù)制
主庫(kù)寫入binlog后強(qiáng)制同步日志到從庫(kù)，所有的從庫(kù)都執(zhí)行完成后才返回給客戶端，但是很顯然這個(gè)方式的話性能會(huì)受到嚴(yán)重影響。
半同步復(fù)制
半同步復(fù)制的邏輯是這樣，從庫(kù)寫入日志成功后返回ACK確認(rèn)給主庫(kù)，主庫(kù)收到至少一個(gè)從庫(kù)的確認(rèn)就認(rèn)為寫操作完成。
還可以延伸到由于主從配置不一樣、主庫(kù)大事務(wù)、從庫(kù)壓力過(guò)大、網(wǎng)絡(luò)震蕩等造成主備延遲，如何避免這個(gè)問(wèn)題？主備切換的時(shí)候用可靠性優(yōu)先原則還是可用性優(yōu)先原則？如何判斷主庫(kù)Crash了？互為主備的情況下如何避免主備循環(huán)復(fù)制？被刪庫(kù)跑路了如何正確恢復(fù)？( o )… 感覺越來(lái)越扯到DBA的活兒上去了。
RedoLog
可以先通過(guò)下面demo理解：
飯點(diǎn)記賬可以把賬單寫在賬本上也可以寫在粉板上。有人賒賬或者還賬的話，一般有兩種做法：
1、直接把賬本翻出來(lái)，把這次賒的賬加上去或者扣除掉。
2、先在粉板上記下這次的賬，等打烊以后再把賬本翻出來(lái)核算。
生意忙時(shí)選后者，因?yàn)榍罢咛闊┝?。得在密密麻麻的記錄中找到這個(gè)人的賒賬總額信息，找到之后再拿出算盤計(jì)算，最后再將結(jié)果寫回到賬本上。
同樣在MySQL中如果每一次的更新操作都需要寫進(jìn)磁盤，然后磁盤也要找到對(duì)應(yīng)的那條記錄，然后再更新，整個(gè)過(guò)程IO成本、查找成本都很高。而粉板和賬本配合的整個(gè)過(guò)程就是MySQL用到的是Write-Ahead Logging 技術(shù)，它的關(guān)鍵點(diǎn)就是先寫日志，再寫磁盤。此時(shí)賬本 = BinLog，粉板 = RedoLog。
1、 記錄更新時(shí)，InnoDB引擎就會(huì)先把記錄寫到RedoLog（粉板）里面，并更新內(nèi)存。同時(shí)，InnoDB引擎會(huì)在空閑時(shí)將這個(gè)操作記錄更新到磁盤里面。
2、 如果更新太多RedoLog處理不了的時(shí)候，需先將RedoLog部分?jǐn)?shù)據(jù)寫到磁盤，然后擦除RedoLog部分?jǐn)?shù)據(jù)。RedoLog類似轉(zhuǎn)盤。
RedoLog有write pos 跟checkpoint
write pos ：是當(dāng)前記錄的位置，一邊寫一邊后移，寫到第3號(hào)文件末尾后就回到0號(hào)文件開頭。
check point：是當(dāng)前要擦除的位置，也是往后推移并且循環(huán)的，擦除記錄前要把記錄更新到數(shù)據(jù)文件。
write pos和check point之間的是粉板上還空著的部分，可以用來(lái)記錄新的操作。如果write pos追上checkpoint，表示粉板滿了，這時(shí)候不能再執(zhí)行新的更新，得停下來(lái)先擦掉一些記錄，把checkpoint推進(jìn)一下。
有了redo log，InnoDB就可以保證即使數(shù)據(jù)庫(kù)發(fā)生異常重啟，之前提交的記錄都不會(huì)丟失，這個(gè)能力稱為crash-safe。 redolog兩階段提交：為了讓binlog跟redolog兩份日志之間的邏輯一致。提交流程大致如下：
1 prepare階段 -- 2 寫binlog -- 3 commit
當(dāng)在2之前崩潰時(shí)，重啟恢復(fù)后發(fā)現(xiàn)沒有commit，回滾。備份恢復(fù)：沒有binlog 。一致
當(dāng)在3之前崩潰時(shí)，重啟恢復(fù)發(fā)現(xiàn)雖沒有commit，但滿足prepare和binlog完整，所以重啟后會(huì)自動(dòng)commit。備份：有binlog. 一致
binlog跟redolog區(qū)別：
redo log是InnoDB引擎特有的；binlog是MySQL的Server層實(shí)現(xiàn)的，所有引擎都可以使用。
redo log是物理日志，記錄的是在某個(gè)數(shù)據(jù)頁(yè)上做了什么修改；binlog是邏輯日志，記錄的是這個(gè)語(yǔ)句的原始邏輯，比如給ID=2這一行的c字段加1。
redo log是循環(huán)寫的，空間固定會(huì)用完；binlog是可以追加寫入的。追加寫是指binlog文件寫到一定大小后會(huì)切換到下一個(gè)，并不會(huì)覆蓋以前的日志。
UndoLog
UndoLog 一般是邏輯日志，主要分為兩種：
insert undo log
代表事務(wù)在insert新記錄時(shí)產(chǎn)生的undo log, 只在事務(wù)回滾時(shí)需要，并且在事務(wù)提交后可以被立即丟棄
update undo log
事務(wù)在進(jìn)行update或delete時(shí)產(chǎn)生的undo log; 不僅在事務(wù)回滾時(shí)需要，在快照讀時(shí)也需要；所以不能隨便刪除，只有在快速讀或事務(wù)回滾不涉及該日志時(shí)，對(duì)應(yīng)的日志才會(huì)被purge線程統(tǒng)一清除
3、MySQL中的索引
索引的常見模型有哈希表、有序數(shù)組和搜索樹。
哈希表：一種以KV存儲(chǔ)數(shù)據(jù)的結(jié)構(gòu)，只適合等值查詢，不適合范圍查詢。
有序數(shù)組：只適用于靜態(tài)存儲(chǔ)引擎，涉及到插入的時(shí)候比較麻煩。可以參考Java中的ArrayList。
搜索樹：按照數(shù)據(jù)結(jié)構(gòu)中的二叉樹來(lái)存儲(chǔ)數(shù)據(jù)，不過(guò)此時(shí)是N叉樹(B+樹)。廣泛應(yīng)用在存儲(chǔ)引擎層中。
B+樹比B樹優(yōu)勢(shì)在于：
B+ 樹非葉子節(jié)點(diǎn)存儲(chǔ)的只是索引，可以存儲(chǔ)的更多。B+樹比B樹更加矮胖，IO次數(shù)更少。
B+ 樹葉子節(jié)點(diǎn)前后管理，更加方便范圍查詢。同時(shí)結(jié)果都在葉子節(jié)點(diǎn)，查詢效率穩(wěn)定。
B+樹中更有利于對(duì)數(shù)據(jù)掃描，可以避免B樹的回溯掃描。
索引的優(yōu)點(diǎn)：
1、唯一索引可以保證每一行數(shù)據(jù)的唯一性
2、提高查詢速度
3、加速表與表的連接
4、顯著的減少查詢中分組和排序的時(shí)間
5、通過(guò)使用索引，可以在查詢的過(guò)程中，使用優(yōu)化隱藏器，提高系統(tǒng)的性能。
索引的缺點(diǎn)：
1、創(chuàng)建跟維護(hù)都需要耗時(shí)
2、創(chuàng)建索引時(shí)，需要對(duì)表加鎖，在鎖表的同時(shí)，可能會(huì)影響到其他的數(shù)據(jù)操作
3、 索引需要磁盤的空間進(jìn)行存儲(chǔ)，磁盤占用也很快。
4、當(dāng)對(duì)表中的數(shù)據(jù)進(jìn)行CRUD的時(shí)，也會(huì)觸發(fā)索引的維護(hù)，而維護(hù)索引需要時(shí)間，可能會(huì)降低數(shù)據(jù)操作性能
索引設(shè)計(jì)的原則不應(yīng)該：
1、索引不是越多越好。索引太多，維護(hù)索引需要時(shí)間跟空間。
2、 頻繁更新的數(shù)據(jù)，不宜建索引。
3、數(shù)據(jù)量小的表沒必要建立索引。
應(yīng)該：
1、重復(fù)率小的列建議生成索引。因?yàn)橹貜?fù)數(shù)據(jù)少，索引樹查詢更有效率，等價(jià)基數(shù)越大越好。
2、數(shù)據(jù)具有唯一性，建議生成唯一性索引。在數(shù)據(jù)庫(kù)的層面，保證數(shù)據(jù)正確性
3、頻繁group by、order by的列建議生成索引?？梢源蠓岣叻纸M和排序效率
4、經(jīng)常用于查詢條件的字段建議生成索引。通過(guò)索引查詢，速度更快
索引失效的場(chǎng)景
1、模糊搜索：左模糊或全模糊都會(huì)導(dǎo)致索引失效，比如'%a'和'%a%'。但是右模糊是可以利用索引的，比如'a%' 。
2、隱式類型轉(zhuǎn)換：比如select * from t where name = xxx , name是字符串類型，但是沒有加引號(hào)，所以是由MySQL隱式轉(zhuǎn)換的，所以會(huì)讓索引失效 3、當(dāng)語(yǔ)句中帶有or的時(shí)候：比如select * from t where name=‘sw’ or age=14
4、不符合聯(lián)合索引的最左前綴匹配：(A,B,C)的聯(lián)合索引，你只where了C或B或只有B,C
關(guān)于索引的知識(shí)點(diǎn)：
主鍵索引：主鍵索引的葉子節(jié)點(diǎn)存的是整行數(shù)據(jù)信息。在InnoDB里，主鍵索引也被稱為聚簇索引（clustered index）。主鍵自增是無(wú)法保證完全自增的哦，遇到唯一鍵沖突、事務(wù)回滾等都可能導(dǎo)致不連續(xù)。
唯一索引：以唯一列生成的索引，該列不允許有重復(fù)值，但允許有空值(NULL)
普通索引跟唯一索引查詢性能：InnoDB的數(shù)據(jù)是按數(shù)據(jù)頁(yè)為單位來(lái)讀寫的，默認(rèn)每頁(yè)16KB，因此這兩種索引查詢數(shù)據(jù)性能差別微乎其微。
change buffer：普通索引用在更新過(guò)程的加速，更新的字段如果在緩存中，如果是普通索引則直接更新即可。如果是唯一索引需要將所有數(shù)據(jù)讀入內(nèi)存來(lái)確保不違背唯一性，所以盡量用普通索引。
非主鍵索引：非主鍵索引的葉子節(jié)點(diǎn)內(nèi)容是主鍵的值。在InnoDB里，非主鍵索引也被稱為二級(jí)索引（secondary index）
回表：先通過(guò)數(shù)據(jù)庫(kù)索引掃描出數(shù)據(jù)所在的行，再通過(guò)行主鍵id取出索引中未提供的數(shù)據(jù)，即基于非主鍵索引的查詢需要多掃描一棵索引樹。
覆蓋索引：如果一個(gè)索引包含（或者說(shuō)覆蓋）所有需要查詢的字段的值，我們就稱之為覆蓋索引。
聯(lián)合索引：相對(duì)單列索引，組合索引是用多個(gè)列組合構(gòu)建的索引，一次性最多聯(lián)合16個(gè)。
最左前綴原則：對(duì)多個(gè)字段同時(shí)建立的組合索引(有順序，ABC，ACB是完全不同的兩種聯(lián)合索引) 以聯(lián)合索引(a,b,c)為例，建立這樣的索引相當(dāng)于建立了索引a、ab、abc三個(gè)索引。另外組合索引實(shí)際還是一個(gè)索引，并非真的創(chuàng)建了多個(gè)索引，只是產(chǎn)生的效果等價(jià)于產(chǎn)生多個(gè)索引。
索引下推：MySQL 5.6引入了索引下推優(yōu)化，可以在索引遍歷過(guò)程中，對(duì)索引中包含的字段先做判斷，過(guò)濾掉不符合條件的記錄，減少回表字?jǐn)?shù)。
索引維護(hù)：B+樹為了維護(hù)索引有序性涉及到頁(yè)分裂跟頁(yè)合并。增刪數(shù)據(jù)時(shí)需考慮頁(yè)空間利用率。
自增主鍵：一般會(huì)建立與業(yè)務(wù)無(wú)關(guān)的自增主鍵，不會(huì)觸發(fā)葉子節(jié)點(diǎn)分裂。
延遲關(guān)聯(lián)：通過(guò)使用覆蓋索引查詢返回需要的主鍵，再根據(jù)主鍵關(guān)聯(lián)原表獲得需要的數(shù)據(jù)。
InnoDB存儲(chǔ): * .frm文件是一份定義文件，也就是定義數(shù)據(jù)庫(kù)表是一張?jiān)趺礃拥谋怼?.ibd文件則是該表的索引，數(shù)據(jù)存儲(chǔ)文件，既該表的所有索引樹，所有行記錄數(shù)據(jù)都存儲(chǔ)在該文件中。
MyISAM存儲(chǔ)：* .frm文件是一份定義文件，也就是定義數(shù)據(jù)庫(kù)表是一張?jiān)趺礃拥谋怼? .MYD文件是MyISAM存儲(chǔ)引擎表的所有行數(shù)據(jù)的文件。* .MYI文件存放的是MyISAM存儲(chǔ)引擎表的索引相關(guān)數(shù)據(jù)的文件。MyISAM引擎下，表數(shù)據(jù)和表索引數(shù)據(jù)是分開存儲(chǔ)的。
MyISAM查詢：在MyISAM下，主鍵索引和輔助鍵索引都屬于非聚簇索引。查詢不管是走主鍵索引，還是非主鍵索引，在葉子結(jié)點(diǎn)得到的都是目的數(shù)據(jù)的地址，還需要通過(guò)該地址，才能在數(shù)據(jù)文件中找到目的數(shù)據(jù)。
PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引
4、SQL事務(wù)隔離級(jí)別
ACID的四個(gè)特性
原子性（Atomicity）：把多個(gè)操作放到一個(gè)事務(wù)中，保證這些操作要么都成功，要么都不成功
一致性（Consistency）：理解成一串對(duì)數(shù)據(jù)進(jìn)行操作的程序執(zhí)行下來(lái)，不會(huì)對(duì)數(shù)據(jù)產(chǎn)生不好的影響，比如憑空產(chǎn)生，或消失
隔離性（Isolation，又稱獨(dú)立性）：隔離性的意思就是多個(gè)事務(wù)之間互相不干擾，即使是并發(fā)事務(wù)的情況下，他們只是兩個(gè)并發(fā)執(zhí)行沒有交集，互不影響的東西；當(dāng)然實(shí)現(xiàn)中，也不一定需要這么完整隔離性，即不一定需要這么的互不干擾，有時(shí)候還是允許有部分干擾的。所以MySQL可以支持4種事務(wù)隔離性
持久性（Durability）：當(dāng)某個(gè)操作操作完畢了，那么結(jié)果就是這樣了，并且這個(gè)操作會(huì)持久化到日志記錄中
PS：ACID中C與CAP定理中C的區(qū)別
ACID的C著重強(qiáng)調(diào)單數(shù)據(jù)庫(kù)事務(wù)操作時(shí)，要保證數(shù)據(jù)的完整和正確性，數(shù)據(jù)不會(huì)憑空消失跟增加。CAP 理論中的C指的是對(duì)一個(gè)數(shù)據(jù)多個(gè)備份的讀寫一致性
事務(wù)操作可能會(huì)出現(xiàn)的數(shù)據(jù)問(wèn)題
1、臟讀(dirty read)：B事務(wù)更改數(shù)據(jù)還未提交，A事務(wù)已經(jīng)看到并且用了。B事務(wù)如果回滾，則A事務(wù)做錯(cuò)了
2、 不可重復(fù)讀(non-repeatable read)：不可重復(fù)讀的重點(diǎn)是修改: 同樣的條件, 你讀取過(guò)的數(shù)據(jù), 再次讀取出來(lái)發(fā)現(xiàn)值不一樣了，只需要鎖住滿足條件的記錄
3、 幻讀(phantom read)：事務(wù)A先修改了某個(gè)表的所有紀(jì)錄的狀態(tài)字段為已處理，未提交；事務(wù)B也在此時(shí)新增了一條未處理的記錄，并提交了；事務(wù)A隨后查詢記錄，卻發(fā)現(xiàn)有一條記錄是未處理的造成幻讀現(xiàn)象，幻讀僅專指新插入的行。幻讀會(huì)造成語(yǔ)義上的問(wèn)題跟數(shù)據(jù)一致性問(wèn)題。
4、 在可重復(fù)讀RR隔離級(jí)別下，普通查詢是快照讀，是不會(huì)看到別的事務(wù)插入的數(shù)據(jù)的。因此，幻讀在當(dāng)前讀下才會(huì)出現(xiàn)。要用間隙鎖解決此問(wèn)題。
在說(shuō)隔離級(jí)別之前，你首先要知道，你隔離得越嚴(yán)實(shí)，效率就會(huì)越低。因此很多時(shí)候，我們都要在二者之間尋找一個(gè)平衡點(diǎn)。SQL標(biāo)準(zhǔn)的事務(wù)隔離級(jí)別由低到高如下： 上圖從上到下的模式會(huì)導(dǎo)致系統(tǒng)的并行性能依次降低，安全性依次提高。
讀未提交：別人改數(shù)據(jù)的事務(wù)尚未提交，我在我的事務(wù)中也能讀到。
讀已提交(Oracle默認(rèn))：別人改數(shù)據(jù)的事務(wù)已經(jīng)提交，我在我的事務(wù)中才能讀到。
可重復(fù)讀(MySQL默認(rèn))：別人改數(shù)據(jù)的事務(wù)已經(jīng)提交，我在我的事務(wù)中也不去讀，以此保證重復(fù)讀一致性。
串行：我的事務(wù)尚未提交，別人就別想改數(shù)據(jù)。
標(biāo)準(zhǔn)跟實(shí)現(xiàn)：上面都是關(guān)于事務(wù)的標(biāo)準(zhǔn)，但是每一種數(shù)據(jù)庫(kù)都有不同的實(shí)現(xiàn)，比如MySQL InnDB 默認(rèn)為RR級(jí)別，但是不會(huì)出現(xiàn)幻讀。因?yàn)楫?dāng)事務(wù)A更新了所有記錄的某個(gè)字段，此時(shí)事務(wù)A會(huì)獲得對(duì)這個(gè)表的表鎖，因?yàn)槭聞?wù)A還沒有提交，所以事務(wù)A獲得的鎖沒有釋放，此時(shí)事務(wù)B在該表插入新記錄，會(huì)因?yàn)闊o(wú)法獲得該表的鎖，則導(dǎo)致插入操作被阻塞。只有事務(wù)A提交了事務(wù)后，釋放了鎖，事務(wù)B才能進(jìn)行接下去的操作。所以可以說(shuō) MySQL的RR級(jí)別的隔離是已經(jīng)實(shí)現(xiàn)解決了臟讀，不可重復(fù)讀和幻讀的。
5、MySQL中的鎖
無(wú)論是Java的并發(fā)編程還是數(shù)據(jù)庫(kù)的并發(fā)操作都會(huì)涉及到鎖，研發(fā)人員引入了悲觀鎖跟樂(lè)觀鎖這樣一種鎖的設(shè)計(jì)思想。
悲觀鎖：
優(yōu)點(diǎn)：適合在寫多讀少的并發(fā)環(huán)境中使用，雖然無(wú)法維持非常高的性能，但是在樂(lè)觀鎖無(wú)法提更好的性能前提下，可以做到數(shù)據(jù)的安全性
缺點(diǎn)：加鎖會(huì)增加系統(tǒng)開銷，雖然能保證數(shù)據(jù)的安全，但數(shù)據(jù)處理吞吐量低，不適合在讀書寫少的場(chǎng)合下使用
樂(lè)觀鎖：
優(yōu)點(diǎn)：在讀多寫少的并發(fā)場(chǎng)景下，可以避免數(shù)據(jù)庫(kù)加鎖的開銷，提高DAO層的響應(yīng)性能，很多情況下ORM工具都有帶有樂(lè)觀鎖的實(shí)現(xiàn)，所以這些方法不一定需要我們?nèi)藶榈娜?shí)現(xiàn)。
缺點(diǎn)：在寫多讀少的并發(fā)場(chǎng)景下，即在寫操作競(jìng)爭(zhēng)激烈的情況下，會(huì)導(dǎo)致CAS多次重試，沖突頻率過(guò)高，導(dǎo)致開銷比悲觀鎖更高。
實(shí)現(xiàn)：數(shù)據(jù)庫(kù)層面的樂(lè)觀鎖其實(shí)跟CAS思想類似， 通數(shù)據(jù)版本號(hào)或者時(shí)間戳也可以實(shí)現(xiàn)。
數(shù)據(jù)庫(kù)并發(fā)場(chǎng)景主要有三種：
讀-讀：不存在任何問(wèn)題，也不需要并發(fā)控制
讀-寫：有隔離性問(wèn)題，可能遇到臟讀，幻讀，不可重復(fù)讀
寫-寫：可能存更新丟失問(wèn)題，比如第一類更新丟失，第二類更新丟失
兩類更新丟失問(wèn)題：
第一類更新丟失：事務(wù)A的事務(wù)回滾覆蓋了事務(wù)B已提交的結(jié)果 第二類更新丟失：事務(wù)A的提交覆蓋了事務(wù)B已提交的結(jié)果
為了合理貫徹落實(shí)鎖的思想，MySQL中引入了雜七雜八的各種鎖：
鎖分類
MySQL支持三種層級(jí)的鎖定，分別為
表級(jí)鎖定
MySQL中鎖定粒度最大的一種鎖，最常使用的MYISAM與INNODB都支持表級(jí)鎖定。
頁(yè)級(jí)鎖定
是MySQL中鎖定粒度介于行級(jí)鎖和表級(jí)鎖中間的一種鎖，表級(jí)鎖速度快，但沖突多，行級(jí)沖突少，但速度慢。所以取了折衷的頁(yè)級(jí)，一次鎖定相鄰的一組記錄。
行級(jí)鎖定
Mysql中鎖定粒度最細(xì)的一種鎖，表示只針對(duì)當(dāng)前操作的行進(jìn)行加鎖。行級(jí)鎖能大大減少數(shù)據(jù)庫(kù)操作的沖突。其加鎖粒度最小，但加鎖的開銷也最大行級(jí)鎖不一定比表級(jí)鎖要好：鎖的粒度越細(xì)，代價(jià)越高，相比表級(jí)鎖在表的頭部直接加鎖，行級(jí)鎖還要掃描找到對(duì)應(yīng)的行對(duì)其上鎖，這樣的代價(jià)其實(shí)是比較高的，所以表鎖和行鎖各有所長(zhǎng)。
MyISAM中的鎖
雖然MySQL支持表，頁(yè)，行三級(jí)鎖定，但MyISAM存儲(chǔ)引擎只支持表鎖。所以MyISAM的加鎖相對(duì)比較開銷低，但數(shù)據(jù)操作的并發(fā)性能相對(duì)就不高。但如果寫操作都是尾插入，那還是可以支持一定程度的讀寫并發(fā)
從MyISAM所支持的鎖中也可以看出，MyISAM是一個(gè)支持讀讀并發(fā)，但不支持通用讀寫并發(fā)，寫寫并發(fā)的數(shù)據(jù)庫(kù)引擎，所以它更適合用于讀多寫少的應(yīng)用場(chǎng)合，一般工程中也用的較少。
InnoDB中的鎖
該模式下支持的鎖實(shí)在是太多了，具體如下：
共享鎖和排他鎖 (Shared and Exclusive Locks)
意向鎖（Intention Locks）
記錄鎖（Record Locks）
間隙鎖（Gap Locks）
臨鍵鎖 （Next-Key Locks）
插入意向鎖（Insert Intention Locks）
主鍵自增鎖 (AUTO-INC Locks)
空間索引斷言鎖（Predicate Locks for Spatial Indexes）
舉個(gè)栗子，比如行鎖里的共享鎖跟排它鎖：lock in share modle 共享讀鎖：
為了確保自己查到的數(shù)據(jù)沒有被其他的事務(wù)正在修改，也就是說(shuō)確保查到的數(shù)據(jù)是最新的數(shù)據(jù)，并且不允許其他人來(lái)修改數(shù)據(jù)。但是自己不一定能夠修改數(shù)據(jù)，因?yàn)橛锌赡芷渌氖聞?wù)也對(duì)這些數(shù)據(jù)使用了 in share mode 的方式上了S 鎖。如果不及時(shí)的commit 或者rollback 也可能會(huì)造成大量的事務(wù)等待。
for update排它寫鎖:
為了讓自己查到的數(shù)據(jù)確保是最新數(shù)據(jù)，并且查到后的數(shù)據(jù)只允許自己來(lái)修改的時(shí)候，需要用到for update。相當(dāng)于一個(gè) update 語(yǔ)句。在業(yè)務(wù)繁忙的情況下，如果事務(wù)沒有及時(shí)的commit或者rollback 可能會(huì)造成其他事務(wù)長(zhǎng)時(shí)間的等待，從而影響數(shù)據(jù)庫(kù)的并發(fā)使用效率。
Gap Lock間隙鎖：
1、行鎖只能鎖住行，如果在記錄之間的間隙插入數(shù)據(jù)就無(wú)法解決了，因此MySQL引入了間隙鎖(Gap Lock)。間隙鎖是左右開區(qū)間。間隙鎖之間不會(huì)沖突。
2、間隙鎖和行鎖合稱NextKeyLock，每個(gè)NextKeyLock是前開后閉區(qū)間。
間隙鎖加鎖原則(學(xué)完忘那種)：
1、加鎖的基本單位是 NextKeyLock，是前開后閉區(qū)間。
2、查找過(guò)程中訪問(wèn)到的對(duì)象才會(huì)加鎖。
3、索引上的等值查詢，給唯一索引加鎖的時(shí)候，NextKeyLock退化為行鎖。
4、索引上的等值查詢，向右遍歷時(shí)且最后一個(gè)值不滿足等值條件的時(shí)候，NextKeyLock退化為間隙鎖。
5、唯一索引上的范圍查詢會(huì)訪問(wèn)到不滿足條件的第一個(gè)值為止。
分別是原子性、一致性、隔離性、持久性。
原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾，因此事務(wù)的操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫(kù)，如果操作失敗則不能對(duì)數(shù)據(jù)庫(kù)有任何影響。
一致性是指事務(wù)必須使數(shù)據(jù)庫(kù)從一個(gè)一致性狀態(tài)變換到另一個(gè)一致性狀態(tài)，也就是說(shuō)一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后都必須處于一致性狀態(tài)。舉例來(lái)說(shuō)，假設(shè)用戶A和用戶B兩者的錢加起來(lái)一共是1000，那么不管A和B之間如何轉(zhuǎn)賬、轉(zhuǎn)幾次賬，事務(wù)結(jié)束后兩個(gè)用戶的錢相加起來(lái)應(yīng)該還得是1000，這就是事務(wù)的一致性。
隔離性是當(dāng)多個(gè)用戶并發(fā)訪問(wèn)數(shù)據(jù)庫(kù)時(shí)，比如同時(shí)操作同一張表時(shí)，數(shù)據(jù)庫(kù)為每一個(gè)用戶開啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個(gè)并發(fā)事務(wù)之間要相互隔離。關(guān)于事務(wù)的隔離性數(shù)據(jù)庫(kù)提供了多種隔離級(jí)別，稍后會(huì)介紹到。
持久性是指一個(gè)事務(wù)一旦被提交了，那么對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫(kù)系統(tǒng)遇到故障的情況下也不會(huì)丟失提交事務(wù)的操作。例如我們?cè)谑褂肑DBC操作數(shù)據(jù)庫(kù)時(shí)，在提交事務(wù)方法后，提示用戶事務(wù)操作完成，當(dāng)我們程序執(zhí)行完成直到看到提示后，就可以認(rèn)定事務(wù)已經(jīng)正確提交，即使這時(shí)候數(shù)據(jù)庫(kù)出現(xiàn)了問(wèn)題，也必須要將我們的事務(wù)完全執(zhí)行完成。否則的話就會(huì)造成我們雖然看到提示事務(wù)處理完畢，但是數(shù)據(jù)庫(kù)因?yàn)楣收隙鴽]有執(zhí)行事務(wù)的重大錯(cuò)誤。這是不允許的。
在數(shù)據(jù)庫(kù)操作中，在并發(fā)的情況下可能出現(xiàn)如下問(wèn)題：
正是為了解決以上情況，數(shù)據(jù)庫(kù)提供了幾種隔離級(jí)別。
數(shù)據(jù)庫(kù)事務(wù)的隔離級(jí)別有4個(gè)，由低到高依次為Read uncommitted(未授權(quán)讀取、讀未提交)、Read committed（授權(quán)讀取、讀提交）、Repeatable read（可重復(fù)讀?。?、Serializable（序列化），這四個(gè)級(jí)別可以逐個(gè)解決臟讀、不可重復(fù)讀、幻象讀這幾類問(wèn)題。
雖然數(shù)據(jù)庫(kù)的隔離級(jí)別可以解決大多數(shù)問(wèn)題，但是靈活度較差，為此又提出了悲觀鎖和樂(lè)觀鎖的概念。
悲觀鎖，它指的是對(duì)數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來(lái)自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度。因此，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制。也只有數(shù)據(jù)庫(kù)層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問(wèn)的排他性，否則，即使在本系統(tǒng)的數(shù)據(jù)訪問(wèn)層中實(shí)現(xiàn)了加鎖機(jī)制，也無(wú)法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)。
商品t_items表中有一個(gè)字段status，status為1代表商品未被下單，status為2代表商品已經(jīng)被下單（此時(shí)該商品無(wú)法再次下單），那么我們對(duì)某個(gè)商品下單時(shí)必須確保該商品status為1。假設(shè)商品的id為1。
如果不采用鎖，那么操作方法如下：
但是上面這種場(chǎng)景在高并發(fā)訪問(wèn)的情況下很可能會(huì)出現(xiàn)問(wèn)題。例如當(dāng)?shù)谝徊讲僮髦?，查詢出?lái)的商品status為1。但是當(dāng)我們執(zhí)行第三步Update操作的時(shí)候，有可能出現(xiàn)其他人先一步對(duì)商品下單把t_items中的status修改為2了，但是我們并不知道數(shù)據(jù)已經(jīng)被修改了，這樣就可能造成同一個(gè)商品被下單2次，使得數(shù)據(jù)不一致。所以說(shuō)這種方式是不安全的。
在上面的場(chǎng)景中，商品信息從查詢出來(lái)到修改，中間有一個(gè)處理訂單的過(guò)程，使用悲觀鎖的原理就是，當(dāng)我們?cè)诓樵兂鰐_items信息后就把當(dāng)前的數(shù)據(jù)鎖定，直到我們修改完畢后再解鎖。那么在這個(gè)過(guò)程中，因?yàn)閠_items被鎖定了，就不會(huì)出現(xiàn)有第三者來(lái)對(duì)其進(jìn)行修改了。需要注意的是，要使用悲觀鎖，我們必須關(guān)閉mysql數(shù)據(jù)庫(kù)的自動(dòng)提交屬性，因?yàn)镸ySQL默認(rèn)使用autocommit模式，也就是說(shuō)，當(dāng)你執(zhí)行一個(gè)更新操作后，MySQL會(huì)立刻將結(jié)果進(jìn)行提交。我們可以使用命令設(shè)置MySQL為非autocommit模式： set autocommit=0;
設(shè)置完autocommit后，我們就可以執(zhí)行我們的正常業(yè)務(wù)了。具體如下：
上面的begin/commit為事務(wù)的開始和結(jié)束，因?yàn)樵谇耙徊轿覀冴P(guān)閉了mysql的autocommit，所以需要手動(dòng)控制事務(wù)的提交。
上面的第一步我們執(zhí)行了一次查詢操作： select status from t_items where id=1 for update; 與普通查詢不一樣的是，我們使用了 select…for update 的方式，這樣就通過(guò)數(shù)據(jù)庫(kù)實(shí)現(xiàn)了悲觀鎖。此時(shí)在t_items表中，id為1的那條數(shù)據(jù)就被我們鎖定了，其它的事務(wù)必須等本次事務(wù)提交之后才能執(zhí)行。這樣我們可以保證當(dāng)前的數(shù)據(jù)不會(huì)被其它事務(wù)修改。需要注意的是，在事務(wù)中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一個(gè)數(shù)據(jù)時(shí)才會(huì)等待其它事務(wù)結(jié)束后才執(zhí)行，一般 SELECT ... 則不受此影響。拿上面的實(shí)例來(lái)說(shuō)，當(dāng)我執(zhí)行 select status from t_items where id=1 for update; 后。我在另外的事務(wù)中如果再次執(zhí)行 select status from t_items where id=1 for update; 則第二個(gè)事務(wù)會(huì)一直等待第一個(gè)事務(wù)的提交，此時(shí)第二個(gè)查詢處于阻塞的狀態(tài)，但是如果我是在第二個(gè)事務(wù)中執(zhí)行 select status from t_items where id=1; 則能正常查詢出數(shù)據(jù)，不會(huì)受第一個(gè)事務(wù)的影響。
使用 select…for update 會(huì)把數(shù)據(jù)給鎖住，不過(guò)我們需要注意一些鎖的級(jí)別，MySQL InnoDB默認(rèn)Row-Level Lock，所以只有「明確」地指定主鍵或者索引，MySQL 才會(huì)執(zhí)行Row lock (只鎖住被選取的數(shù)據(jù)) ，否則MySQL 將會(huì)執(zhí)行Table Lock (將整個(gè)數(shù)據(jù)表單給鎖住)。舉例如下：
1、 select * from t_items where id=1 for update;
這條語(yǔ)句明確指定主鍵（id=1），并且有此數(shù)據(jù)（id=1的數(shù)據(jù)存在），則采用row lock。只鎖定當(dāng)前這條數(shù)據(jù)。
2、 select * from t_items where id=3 for update;
這條語(yǔ)句明確指定主鍵，但是卻查無(wú)此數(shù)據(jù)，此時(shí)不會(huì)產(chǎn)生lock（沒有元數(shù)據(jù)，又去lock誰(shuí)呢？）。
3、 select * from t_items where name='手機(jī)' for update;
這條語(yǔ)句沒有指定數(shù)據(jù)的主鍵，那么此時(shí)產(chǎn)生table lock，即在當(dāng)前事務(wù)提交前整張數(shù)據(jù)表的所有字段將無(wú)法被查詢。
4、 select * from t_items where id0 for update; 或者 select * from t_items where id1 for update; （注：在SQL中表示不等于）
上述兩條語(yǔ)句的主鍵都不明確，也會(huì)產(chǎn)生table lock。
5、 select * from t_items where status=1 for update; （假設(shè)為status字段添加了索引）
這條語(yǔ)句明確指定了索引，并且有此數(shù)據(jù)，則產(chǎn)生row lock。
6、 select * from t_items where status=3 for update; （假設(shè)為status字段添加了索引）
這條語(yǔ)句明確指定索引，但是根據(jù)索引查無(wú)此數(shù)據(jù)，也就不會(huì)產(chǎn)生lock。
樂(lè)觀鎖（ Optimistic Locking ） 相對(duì)悲觀鎖而言，樂(lè)觀鎖假設(shè)認(rèn)為數(shù)據(jù)一般情況下不會(huì)造成沖突，所以只會(huì)在數(shù)據(jù)進(jìn)行提交更新的時(shí)候，才會(huì)正式對(duì)數(shù)據(jù)的沖突與否進(jìn)行檢測(cè)，如果發(fā)現(xiàn)沖突了，則返回用戶錯(cuò)誤的信息，讓用戶決定如何去做。實(shí)現(xiàn)樂(lè)觀鎖一般來(lái)說(shuō)有以下2種方式：
重慶分公司
重慶分公司
