頁級的典型代表引擎為BDB。 表級的典型代表引擎為MyISAM,MEMORY以及很久以前的ISAM。 行級的典型代表引擎為INNODB。
頁級的典型代表引擎為BDB。
表級的典型代表引擎為MyISAM,MEMORY以及很久以前的ISAM。
行級的典型代表引擎為INNODB。
很多操作都是讀表。
在嚴格條件的索引上讀取和更新，當更新或者刪除可以用單獨的索引來讀取得到時：
UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;
DELETE FROM tbl_name WHERE unique_key_col=key_value;
SELECT 和 INSERT 語句並發的執行，但是只有很少的 UPDATE 和 DELETE 語句。
很多的掃描表和對全表的 GROUP BY 操作，但是沒有任何寫表。
表級鎖和行級鎖或頁級鎖之間的不同之處還在於：
將同時有一個寫和多個讀的地方做版本（例如在MySQL中的並發插入）。也就是說，數據庫教程/表支持根據開始訪問數據時間點的不同支持各種不同的試圖。其它名有：時間行程，寫復制，或者是按需復制。
復制代碼 代碼如下:
//執行SQL語句 鎖掉stat_num表
$sql = "LOCK TABLES stat_num WRITE"; //表的WRITE鎖定，阻塞其他所有mysql教程查詢進程
$DatabaseHandler->exeCute($sql);
//執行更新或寫入操作
$sql = "UPDATE stat_num SET `correct_num`=`correct_num`+1 WHERE stat_date='{$cur_date}'";
$DatabaseHandler->exeCute($sql);
//當前請求的所有寫操作做完後，執行解鎖sql語句
$sql = "UNLOCK TABLES";
$DatabaseHandler->exeCute($sql);
-我們實際應用中用的最多的就是行鎖。
行級鎖的優點如下：
1）、當很多連接分別進行不同的查詢時減小LOCK狀態。
2）、如果出現異常，可以減少數據的丟失。因為一次可以只回滾一行或者幾行少量的數據。
行級鎖的缺點如下：
1）、比頁級鎖和表級鎖要占用更多的內存。
2）、進行查詢時比頁級鎖和表級鎖需要的I/O要多，所以我們經常把行級鎖用在寫操作而不是讀操作。
3）、容易出現死鎖。
對於寫鎖定如下：
1）、如果表沒有加鎖，那麼對其加寫鎖定。
2）、否則，那麼把請求放入寫鎖隊列中。
對於讀鎖定如下：
1）、如果表沒有加寫鎖，那麼加一個讀鎖。
2）、否則，那麼把請求放到讀鎖隊列中。
當然我們可以分別用low_priority 以及high_priority在寫和讀操作上來改變這些行為。
如果想要在一個表上做大量的 INSERT 和 SELECT 操作，但是並行的插入卻不可能時，可以將記錄插入到臨時表中，然後定期將臨時表中的數據更新到實際的表裡。可以用以下命令實現：
mysql> LOCK TABLES real_table WRITE, insert_table WRITE;
mysql> INSERT INTO real_table SELECT * FROM insert_table;
mysql> TRUNCATE TABLE insert_table;
mysql> UNLOCK TABLES;
InnoDB 使用行級鎖，BDB 使用頁級鎖。對於 InnoDB 和 BDB 存儲引擎來說，是可能產生死鎖的。這是因為 InnoDB 會自動捕獲行鎖，BDB 會在執行 SQL 語句時捕獲頁鎖的，而不是在事務的開始就這麼做。
行級鎖的優點有：
在很多線程請求不同記錄時減少沖突鎖。
事務回滾時減少改變數據。
使長時間對單獨的一行記錄加鎖成為可能。
行級鎖的缺點有：
比頁級鎖和表級鎖消耗更多的內存。
當在大量表中使用時，比頁級鎖和表級鎖更慢，因為他需要請求更多的所資源。
當需要頻繁對大部分數據做 GROUP BY 操作或者需要頻繁掃描整個表時，就明顯的比其它鎖更糟糕。
使用更高層的鎖的話，就能更方便的支持各種不同的類型應用程序，因為這種鎖的開銷比行級鎖小多了。
表級鎖在下列幾種情況下比頁級鎖和行級鎖更優越：
下面我來一個簡單的例子解釋上面的說法。
我們來運行一個時間很長的查詢
1）、客戶端1：
mysql> select count(*) from content group by content;
...
客戶端2：
mysql> update content set content = 'I love you' where id = 444;
Query OK, 1 row affected (30.68 sec)
Rows matched: 1 Changed: 1 Warnings: 0
用了半分鐘。
2）、我們現在終止客戶端1。
此時客戶端2：
mysql> update content set content = 'I hate you' where id = 444;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0
僅僅用了20毫秒。
這個例子很好的說明了讀寫隊列的運行。
對於1中的客戶端1，此時表沒有加鎖，當然也沒有加寫鎖了，那麼此時客戶端1對表加了一個讀鎖。
對於1中的客戶端2，此時因為表有一個讀鎖，所以把UPDATE請求放到寫鎖定隊列中。
當讀鎖釋放的時候，也就是SHOW PROCESSLIST中STATUS 為COPY TO TMP TABLE的時候，UPDATE操作開始執行。
