MySQL基本調度策略的淺析

MySQL允許影響語(yǔ)句的調度特性，這樣會(huì )使來(lái)自幾個(gè)客戶(hù)機的查詢(xún)更好地協(xié)作，從而單個(gè)客戶(hù)機不會(huì )被鎖定太長(cháng)的時(shí)間。更改調度特性還能保證特定的查詢(xún)處理得更快。我們先來(lái)看一下MySQL的缺省調度策略，然后來(lái)看看為改變這個(gè)策略可使用什么樣的選項。出于討論的目的，假設執行檢索( SELECT)的客戶(hù)機程序為讀取程序。執行修改表操作( DELETE，INSERT，REPLACE 或UP DATE)的另一個(gè)客戶(hù)機程序為寫(xiě)入程序。

MySQL的基本調度策略可總結如下：

◆寫(xiě)入請求應按其到達的次序進(jìn)行處理。

◆寫(xiě)入具有比讀取更高的優(yōu)先權。

在表鎖的幫助下實(shí)現調度策略?？蛻?hù)機程序無(wú)論何時(shí)要訪(fǎng)問(wèn)表，都必須首先獲得該表的鎖?？梢灾苯佑肔OCK TABLES 來(lái)完成這項工作，但一般服務(wù)器的鎖管理器會(huì )在需要時(shí)自動(dòng)獲得鎖。在客戶(hù)機結束對表的處理時(shí)，可釋放表上的鎖。直接獲得的鎖可用UNLOCK TABLES 釋放，但服務(wù)器也會(huì )自動(dòng)釋放它所獲得的鎖。

執行寫(xiě)操作的客戶(hù)機必須對表具有獨占訪(fǎng)問(wèn)的鎖。在寫(xiě)操作進(jìn)行中，由于正在對表進(jìn)行數據記錄的刪除、增加或更改，所以該表處于不一致?tīng)顟B(tài)，而且該表上的索引也可能需要作相應的更新。如果表處于不斷變化中，此時(shí)允許其他客戶(hù)機訪(fǎng)問(wèn)該表會(huì )出問(wèn)題。讓兩個(gè)客戶(hù)機同時(shí)寫(xiě)同一個(gè)表顯然不好，因為這樣會(huì )很快使該表不可用。允許客戶(hù)機讀不斷變化的表也不是件好事，因為可能在讀該表的那一刻正好正在對它進(jìn)行更改，其結果是不正確的。執行讀取操作的客戶(hù)機必須有一把防止其他客戶(hù)機寫(xiě)該表的鎖，以保證讀表的過(guò)程中表不出現變化。不過(guò)，該鎖無(wú)需對讀取操作提供獨占訪(fǎng)問(wèn)。此鎖還允許其他客戶(hù)機同時(shí)對表進(jìn)行讀取。讀取不會(huì )更改表，所有沒(méi)必要阻止其它客戶(hù)機對該表進(jìn)行讀取。

MySQL允許借助幾個(gè)查詢(xún)限修飾符對其調度策略施加影響。其中之一是DELETE、INSERT、LOAD DATA、REPLACE 和UP DATE 語(yǔ)句的LOW_PRIORITY 關(guān)鍵字。另一個(gè)是SELECT 語(yǔ)句的HIGH_PRIORITY 關(guān)鍵字。第三個(gè)是INSERT 和REPLACE 語(yǔ)句的DELAYED 關(guān)鍵字。

LOW_PRIORITY 關(guān)鍵字按如下影響調度。一般情況下，如果某個(gè)表的寫(xiě)入操作在表正被讀取時(shí)到達，寫(xiě)入程序被阻塞，直到讀取程序完成，因為一旦某個(gè)查詢(xún)開(kāi)始，就不能中斷。如果另一讀取請求在寫(xiě)入程序等待時(shí)到達，此讀取程序也被阻塞，因為缺省的調度策略為寫(xiě)入程序具有比讀取程序高的優(yōu)先級。在第一個(gè)讀取程序結束時(shí)，寫(xiě)入程序繼續，在此寫(xiě)入程序結束時(shí)，第二個(gè)讀取程序開(kāi)始。

如果寫(xiě)入請求為L(cháng)OW_PRIORITY 的請求，則不將該寫(xiě)入操作視為具有比讀取操作優(yōu)先級高的操作。在此情形下，如果第二個(gè)讀取請求在寫(xiě)入程序等待時(shí)到達，則讓第二個(gè)讀取操作排在等待的寫(xiě)入操作之前。僅當沒(méi)有其他讀取請求時(shí)，才允許寫(xiě)入程序執行。這種調度的更改從理論上說(shuō)，其含義為L(cháng)OW_PRIORITY 寫(xiě)入可能會(huì )永遠被阻塞。當正在處理前面的讀取請求時(shí)，只要另一個(gè)讀取請求到達，這個(gè)新的請求允許排在LOW_PRIORITY 寫(xiě)入之前。

SELECT 查詢(xún)的HIGH_PRIORITY 關(guān)鍵字作用類(lèi)似。它使SELECT 插在正在等待的寫(xiě)入操作之前，即使該寫(xiě)入操作具有正常的優(yōu)先級。INSERT 的ELAYED 修飾符作用如下，在表的一個(gè)INSERT DELAYED 請求到達時(shí)，服務(wù)器將相應的行放入一個(gè)隊列，并立即返回一個(gè)狀態(tài)到客戶(hù)機程序，以便該客戶(hù)機程序可以繼續執行，即使這些行尚未插入表中。如果讀取程序正在對表進(jìn)行讀取，那么隊列中的行掛起。在沒(méi)有讀取時(shí)，服務(wù)器開(kāi)始開(kāi)始插入延遲行隊列中的行。服務(wù)器不時(shí)地停下來(lái)看看是否有新的讀取請求到達，并進(jìn)行等待。如果是這樣，延遲行隊列將掛起，并允許讀取程序繼續。在沒(méi)有其他的讀取操作時(shí)，服務(wù)器再次開(kāi)始插入延遲行。這個(gè)過(guò)程一直進(jìn)行到延遲行隊列空為止。

此并非出現在所有MySQL版本中。下面的表列出了這些修飾符和支持這些修飾符的MySQL版本?？衫么吮韥?lái)判斷所使用的MySQL版本具有什么樣的功能：

本文引用地址：http://dyxdggzs.com/article/201706/353693.htm如果其他客戶(hù)機可能執行冗長(cháng)的SELECT 語(yǔ)句，而且您不希望等待插入完成，此時(shí)INSERT DELAYED 很有用。發(fā)布INSERT DELAYED 的客戶(hù)機可以更快地繼續執行，因為服務(wù)器只是簡(jiǎn)單地將要插入的行插入。不過(guò)應該對正常的INSERT 和INSERT DELAYED 性能之間的差異有所認識。如果INSERT DELAYED 存在語(yǔ)法錯誤，則向客戶(hù)機發(fā)出一個(gè)錯誤，如果正常，便不發(fā)出信息。例如，在此語(yǔ)句返回時(shí)，不能相信所取得的AUTO_INCREMENT 值。也得不到惟一索引上的重復數目的計數。之所以這樣是因為此插入操作在實(shí)際的插入完成前返回了一個(gè)狀態(tài)。其他還表示，如果INSERT DELAYED 語(yǔ)句的行在等待插入中被排隊，并且服務(wù)器崩潰或被終止(用kill -9)，那么這些行將丟失。正常的TERM 終止不會(huì )這樣，服務(wù)器會(huì )在退出前將這些行插入。