今天來簡單總結(jié)一下MySQL的鎖機(jī)制，不妥的歡迎拍磚！

　　1、對于MySQL來說，有三種鎖的級別：頁級、表級、行級。

　　頁級的典型代表引擎為BDB。

　　表級的典型代表引擎為MyISAM,MEMORY以及很久以前的ISAM。

　　行級的典型代表引擎為INNODB。

　　2、我們實(shí)際應(yīng)用中用的最多的就是行鎖了。

　　行級鎖的優(yōu)點(diǎn)如下：

　　1）、當(dāng)很多連接分別進(jìn)行不同的查詢時(shí)減小LOCK狀態(tài)。

　　2）、如果出現(xiàn)異常，可以減少數(shù)據(jù)的丟失。因?yàn)橐淮慰梢灾换貪L一行或者幾行少量的數(shù)據(jù)。

　　行級鎖的缺點(diǎn)如下：

　　1）、比頁級鎖和表級鎖要占用更多的內(nèi)存。

　　2）、進(jìn)行查詢時(shí)比頁級鎖和表級鎖需要的I/O要多，所以我們經(jīng)常把行級鎖用在寫操作而不是讀操作。

　　3）、容易出現(xiàn)死鎖。

　　3、MySQL用寫隊(duì)列和讀隊(duì)列來實(shí)現(xiàn)對數(shù)據(jù)庫的寫和讀操作。

　　對于寫鎖定如下：

　　1）、如果表沒有加鎖，那么對其加寫鎖定。

　　2）、否則，那么把請求放入寫鎖隊(duì)列中。

　　對于讀鎖定如下：

　　1）、如果表沒有加寫鎖，那么加一個(gè)讀鎖。

　　2）、否則，那么把請求放到讀鎖隊(duì)列中。

　　當(dāng)然我們可以分別用low_priority 以及high_priority在寫和讀操作上來改變這些行為。

　　4、下面我來一個(gè)簡單的例子解釋上面的說法

　　我們來運(yùn)行一個(gè)時(shí)間很長的查詢

　　1）客戶端1：

　　mysql>selectcount(*) from content group by content;

　　...

　　客戶端2：

　　mysql>updatecontent set content = 'I love you' where id = 444;

　　Query OK, 1 row affected (30.68 sec)

　　Rows matched: 1 Changed: 1 Warnings: 0

　　用了半分鐘。

　　2）我們現(xiàn)在終止客戶端1。

　　此時(shí)客戶端2：

　　mysql>updatecontent set content = 'I hate you' where id = 444;

　　Query OK, 1 row affected (0.02 sec)

　　Rows matched: 1 Changed: 1 Warnings: 0

　　僅僅用了20毫秒。

　　這個(gè)例子很好的說明了讀寫隊(duì)列的運(yùn)行。

　　對于1中的客戶端1，此時(shí)表沒有加鎖，當(dāng)然也沒有加寫鎖了，那么此時(shí)客戶端1對表加了一個(gè)讀鎖。

　　對于1中的客戶端2，此時(shí)因?yàn)楸碛幸粋€(gè)讀鎖，所以把UPDATE請求放到寫鎖定隊(duì)列中。

　　當(dāng)讀鎖釋放的時(shí)候，也就是SHOW PROCESSLIST中STATUS 為COPY TO TMP TABLE的時(shí)候，UPDATE操作開始執(zhí)行。

　　5、可以在REPLICATION中對MASTER 和SLAVE運(yùn)用不同的鎖定使系統(tǒng)達(dá)到最佳的性能。（當(dāng)然這個(gè)前提是SQL語句都是最優(yōu)的。）

MYSQL