顧名思義，全局鎖就是對整個數(shù)據(jù)庫實例加鎖。L提供了一個加全局讀鎖的方法，命htableswthredk(FTWR)。當你需要讓整個庫處于只讀狀態(tài)的時候，可以使用這個命令，之后其他線程的以下語句會被阻塞：數(shù)據(jù)更新語句（數(shù)據(jù)的增刪改）據(jù)定義語句（包括建表、修改表結(jié)構(gòu)等）和更新類事務的提交語句。全局鎖的典型使用場景是，做全庫邏輯備份。selectFTWRLbinlog，會導致主從圖1A已經(jīng)多了一門課”。如果后面用這個備份來恢復數(shù)據(jù)的話，用戶A就發(fā)現(xiàn)，自己賺了。自帶的邏輯備份工具是mysqldump。當mysqldump使用參數(shù)–single-transaction的時候，導數(shù)據(jù)之前就會啟動一個事務，來確保拿到一致性視圖。而由于MVCC的支持，支持這個級別。比如，對于MyISAM這種不支持事務的引擎，如果備份過程中有更新， FTWRL命所以，single-transaction如果有的表使用了不支持事務的引擎，那么備份就只能通過FTWRL方法。這往往是DBA要求業(yè)務開發(fā)人員使用InnoDB替代MyISAM的原因之一。你也許會問，既然要全庫只讀，為什么不使用setglobalreadonly=true的方式呢？確readonlyFTWRL一是，在有些系統(tǒng)中，readonly還是備庫。因此，修改global變量的方式影響面更大，我不建議你使用。二是，在異常處理機制上有差異。如果執(zhí)行TWRLSQLredonly之后，如果客戶端發(fā)生異常，則數(shù)據(jù)庫就會一直保持adonly狀態(tài)，這樣會導致整個庫長時間處于不可寫狀態(tài)，風險較高。業(yè)務的更新不只是增刪改數(shù)據(jù)（)，還有可能是加字段等修改表結(jié)構(gòu)的操作（DL）。不論是哪種方法，一個庫被全局鎖上以后，你要對里面任何一個表做加字段操作，都是會被MySQL（metadatalock，表鎖的語法是locktables…read/write。與FTWRL類似，可以用unlocktables主動釋放鎖，也可以在客戶端斷開的時候自動釋放。需要注意，locktables語法除了會限制別舉個例子,如果在某個線程A中執(zhí)行l(wèi)ocktablest1read,t2write;這個語句，則其他線程寫t1、讀寫t2的語句都會被阻塞。同時，線程A在執(zhí)行unlocktables之前，也只能執(zhí)行讀t1、讀寫t2的操作。連寫t1都不允許，自然也不能其他表。在還沒有出現(xiàn)更細粒度的鎖的時候，表鎖是最常用的處理并發(fā)的方式。而對于InnoDB這種支持行鎖的引擎，一般不使用locktables命令來控制并發(fā)，畢竟鎖住整個表的影響面還是另一類表級的鎖是MDL（metadataloc)ML不需要顯式使用，在一個表的時候會被自動加上。MDL的作用是，保證讀寫的正確性。你可以想象一下，如果一個查詢正在遍歷一個表中的數(shù)據(jù)，而執(zhí)行期間另一個線程對這個表結(jié)構(gòu)做變更，刪了一列，那么查詢線程拿到的結(jié)果跟表結(jié)構(gòu)對不上，肯定是不行的。MySQL5.5MDL雖然MDL鎖是系統(tǒng)默認會加的，但卻是你不能忽略的一個機制。比如下面這個例子，我經(jīng)你肯定知道，給一個表加字段，或者修改字段，或者加索引，需要掃描全表的數(shù)據(jù)。在對大表操作的時候，你肯定會特別，以免對線上服務造成影響。而實際上，即使是小表，操作不慎也會出問題。我們來看一下下面的操作序列，假設表t備注：這里的實驗環(huán)境是MySQL5.6sessionAtMDLsessionB的也是MDL讀鎖，因此可以正常執(zhí)行。sessionCblockedsessionAMDLsessionMDLsessionCtMDL的請求也會被sessionC阻塞。前面我們說了，所有對表的增刪改查操作都需要先申請MDL讀鎖，就都被鎖住，等于這個表現(xiàn)在完全不可讀寫了。MDL首先我們要解決長事務，事務不提交，就會一直占著MDL鎖。在MySQL的information_schemainnodb_trxDDL變更的表剛好有長事務在執(zhí)行，要考慮先暫停DDL，或者kill掉這個長事務。這時候kill可能未必管用，因為新的請求馬上就來了。比較理想的機制是，在altertable語句里面設定等待時間，如果在這個指定的等待時間里面能夠拿到MDL寫鎖最好，拿不到也不要阻塞后面的業(yè)務語句，先放棄。之后開發(fā)人員或者DBA再通過重試命令重復這個過程。MariaDBAliSQLDDLNOWAIT/WAITn這個語法。ALTERTABLEtbl_nameNOWAITaddcolumnALTERTABLEtbl_nameWAITNaddcolumn今天，我跟你介紹了MySQL要么是你的系統(tǒng)現(xiàn)在還在用MyISAM這類不支持事務的引擎，那要安排升級換引擎；locktablesunlocktablesbegincommitMDL會直到事務提交才釋放，在做表結(jié)構(gòu)變更的時候，你一定要不要導致鎖住線上查最后，我給你留一個問題吧。備份一般都會在備庫上執(zhí)行，你在用–single-transaction法做邏輯備份的過程中，如果主庫上的一個小表做了一個DDL，比如給一個表上加了一上期的問題是關于對聯(lián)合主鍵索引和InnoDB我直接貼@老楊的回復略作（我修改的部分用橙色標出）：123d132143213222234a，borderbya,babc索引caca–c--|–a--|–主鍵部分b（ab，b）3242這個跟索引ccbcb–c--|–b--|–主鍵部分a--（同上）2223cacb@浪里白條幫大家總結(jié)了復習要點；@MRR@Hn留言言簡意賅。 售賣。頁面已增加防盜追蹤，將依法其上一 05|深入淺出索引（下下一 07|行鎖功過：怎么減少行鎖對性能的影響echo＿陳mysql5.6不是支持onlineddl了嗎？也就是對表操作增加字段等功能，實際上不會阻塞讀OnlineDDL真正做可以正常讀寫數(shù)據(jù)，是因此稱為“online”3 75lionetesFTWRL,FTWRL時候是所有事務都提交完畢的時候mysqldumpsingle-transaction尤其readonlysuper48翟毅翟毅MDL“的留言置頂了，希望有疑問的同學能看到這個39micheonlineddl的copy方式和ince方式，也都是需要拿MDL寫鎖、降成讀鎖、做作者回復:.12作者回復:早啊今天51InnoDB會把主鍵字段放到索引定義字段后面，ps(c,b）的索引，實際上是3 32是一樣的.1 28Tony基于文中的例子MDL（metadatalock)，自己做了一個實驗（稍微有一些小改動在sessionD上），sessionA:begin;select*fromtlimit1;最先啟動sessionAsessionB:begin;select*fromtlimit1sessionBsessionC:altertabletaddfint;然后再是啟動sessionC…orkbenc本號4 251 25據(jù)，此時slave同步正常，不會有問題?！?8 （DDL操作）被前面的sessionA和B（查詢操作，獲取MDL讀鎖）所阻塞。這里13也說了“MDLDDL才會在從…11locktablest1read,t2查了一下MySQLReference：WRITElock:…111 10既然sessionCblocked，拿不到寫鎖，那么sessionD為什么會被blocked8Tony基于文中的例子MDL（metadatalock)，自己做了一個實驗（稍微有一些小改動在sessionD上），sessionA:begin;select*fromtlimit1;最先啟動sessionAsessionB:begin;select*fromtlimit1sessionBsessionC:altertabletaddfint;然后再是啟動sessionC…8上一節(jié)的問題，ca索引的數(shù)據(jù)和c索引一樣，是因為c索引查到數(shù)據(jù)時，回表后返回的數(shù)7請教，我們在一個mysql5.7版本的分區(qū)大表上增加了一個字段，是更新表結(jié)構(gòu)，原本7老師咨詢一個問題，我有一個大表t幾百萬條數(shù)據(jù)，a是主鍵(int類型)，另外有一個索引（b,c,d），查詢語句selectafromtwhereb=‘ZC1093’andc=‘2018-07-31’andd=‘AG011’limit1000,100.014sselectafromtwhereb=‘ZC1093’andc=‘2018-07-31’andd=‘AG011’orderbyalimit1000,10執(zhí)行過程也用了(b,c,d)這個索引卻用了34s完成，兩條查詢語句結(jié)果也都…”orderby6Tony基于文中的例