當併發系統中不同執行緒出現迴圈資源依賴，涉及的執行緒都在等待別的執行緒釋放資源時，就會導致這幾個執行緒都進入無限等待的狀態，稱為死鎖
例如：事務a
事務bbegin;update a set t=t+1 where id=1;
begin
update a set t=t+1 where id=2;
update a set t=t+1 where id =2;
update a set t=t+1 where id =1
事務 a 在等待事務 b 釋放 id=2 的行鎖，而事務 b 在等待事務 a 釋放 id=1 的行鎖。 事務 a 和事務 b 在互相等待對方的資源釋放，就是進入了死鎖狀態
當出現死鎖的二種策略：
發起死鎖檢測，發現死鎖後，主動回滾死鎖鏈條中的某乙個事務，讓其他事務得以繼續執行。將引數innodb_deadlock_detect設定為 on，表示開啟這個邏輯。主動死鎖檢測，而且innodb_deadlock_detect的預設值本身就是 on。主動死鎖檢測在發生死鎖的時候，是能夠快速發現並進行處理的，但是它也是有額外負擔的。
併發引發的問題：
有 1000 個併發執行緒要同時更新同一行，那麼死鎖檢測操作就是 100 萬這個量級的。雖然最終檢測的結果是沒有死鎖，但是這期間要消耗大量的 cpu 資源。因此，你就會看到 cpu 利用率很高，但是每秒卻執行不了幾個事務
怎麼解決這種由熱點行更新導致的效能問題呢？
問題歸根到底就是死鎖檢測要耗費大量的 cpu 資源
如果你能確保這個業務一定不會出現死鎖，可以臨時把死鎖檢測關掉。但是這種操作本身帶有一定的風險，因為業務設計的時候一般不會把死鎖當做乙個嚴重錯誤，畢竟出現死鎖了，就回滾，然後通過業務重試一般就沒問題了，這是業務無損的。而關掉死鎖檢測意味著可能會出現大量的超時，這是業務有損的。
控制併發度,併發能夠控制住，比如同一行同時最多只有 10 個執行緒在更新，那麼死鎖檢測的成本很低，就不會出現這個問題
mysql行 《Mysql 行模式》
一 總結 預設的行格式定義 innodb default row format 檢視當前資料表行格式 show table status table 建立表指定行格式 create table table row format dynamic 修改錶行格式 alter table table row...
mysql行 MySQL 行的詳細操作
閱讀目錄 介紹mysql資料操作 dml 在mysql管理軟體中，可以通過sql語句中的dml語言來實現資料的操作，包括 使用insert實現資料的插入 update實現資料的更新 使用delete實現資料的刪除 使用select查詢資料以及。本節內容包括 插入資料 更新資料 刪除資料 查詢資料 插...
mysql行格式 MySQL 行格式
以 mysql 預設的儲存引擎 innodb 為例 innodb 包含以下四種行格式 compact redundant dynamic compressed 指定行格式 create table 表名 列的資訊 row format 行格式名稱 alter table 表名 row format ...