mysql locked 解決方案

2021-08-25 10:46:41 字數 1639 閱讀 2660

最近發現程式執行速度明顯變慢,而且cpu常常在90%以上!

通過檢測發現瓶頸居然在mysql,通過執行 show processlist 可以看到很多locked的查詢語句,當時過了乙個小時左右locked的情況又不見了。由此可見locked不是死鎖。

那為什麼會出現locked呢?

在mysql中對於使用表級鎖定的儲存引擎,表鎖定時不會死鎖的。這通過總是在乙個查詢開始時立即請求所有必要的鎖定並且總是以同樣的順序鎖定表來管理。

我的**式為myisam

對write,mysql使用的表鎖定方法原理如下:

◆ 如果在表上沒有鎖,在它上面放乙個寫鎖。

◆否則,把鎖定請求放在寫鎖定佇列中。

對read,mysql使用的鎖定方法原理如下:

◆如果在表上沒有寫鎖定,把乙個讀鎖定放在它上面。

◆否則,把鎖請求放在讀鎖定佇列中。

當乙個鎖定被釋放時,鎖定可被寫鎖定佇列中的執行緒得到,然後是讀鎖定佇列中的執行緒。

這意味著,如果你在乙個表上有許多更新,select語句將等待直到沒有更多的更新。

如果insert 語句不衝突,可以自由為myisam 表混合並行的insert 和select 語句而不需要鎖定。

所以說myisam是表鎖,innodb 是行鎖

行級鎖定的優點:

· 當在許多執行緒中訪問不同的行時只存在少量鎖定衝突。

· 回滾時只有少量的更改。

· 可以長時間鎖定單一的行。

行級鎖定的缺點:

· 比頁級或表級鎖定占用更多的記憶體。

· 當在表的大部分中使用時,比頁級或表級鎖定速度慢,因為你必須獲取更多的鎖。

· 如果你在大部分資料上經常進行 group by 操作或者必須經常掃瞄整個表,比其它鎖定明顯慢很多。

· 用高階別鎖定,通過支援不同的型別鎖定,你也可以很容易地調節應用程式,因為其鎖成本小於行級鎖定。

在以下情況下,表鎖定優先於頁級或行級鎖定:

· 表的大部分語句用於讀取。

· 對嚴格的關鍵字進行讀取和更新,你可以更新或刪除可以用單一的讀取的關鍵字來提取的一行:

• 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中使用的技術),其中可以乙個寫操作,同時有許多讀取操作。這明資料庫或表支援資料依賴的不同檢視,取決於訪問何時開始。其它共同的術語是「時間跟蹤」、「寫複製」或者「按需複製」。

· 按需複製在許多情況下優先於頁級或行級鎖定。然而,在最壞的情況下,它可能比使用常規鎖定使用多的記憶體。

· 除了行級鎖定外,你可以使用應用程式級鎖定,例如在mysql中使用get_lock()和release_lock()。這些是建議性鎖定,它們只能在執行良好的應用程式中工作。

而我用的解決方案是用單執行緒,用了乙個查詢服務,對所有資料庫操作都用單執行緒來執行

mysql 解決方案 Mysql解決方案

mysql解決方案 一 centos7安裝mysql5.7 wget rpm uvh mysql80 community release el7 3.noarch.rpm yum repolist all grep mysql 發現預設mysql8.0是預設安裝的,然而我們要安裝的是mysql5.7...

OSSIM解決方案

大多數主流安全產品針對的是計算機單一安全缺陷,他們更多的是提供某一單獨的安全保護功能。目前安全領域內還沒有一套相對完整系統安全解決方案,而且由於主流商業安全軟體的閉源特性,讓我們對其自身的安全特性也不能夠完全信服。隨著軟體開源趨勢的不斷推進,現在出現了很多甚至可以說效能毫不遜色於任何商業軟體的安全工...

android OOM解決方案

解決oom的常用方案 記憶體限制是android對應用的乙個系統級限制,作為應用層開發人員,沒有辦法徹底去消滅這個限制,但是可以通過一些手段去合理使用記憶體,從而規避這個問題。以下是個人總結的一些常用方法 1 快取影象到記憶體,採用軟引用快取到記憶體,而不是在每次使用的時候都從新載入到記憶體 2 調...