版權聲明：本文為博主原創文章，遵循 CC 4.0 by-sa 版權協議，轉載請附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/xuheng8600/article/details/79868122
解決mysql 事務未提交導致死鎖報錯：

????????當 sessionA 嘗試修改 B 表數據，因為 sessionB 當前為鎖定狀態，而且 sessionB 對 B 表中數據具有鎖定狀態中，則出現死鎖。sessionB 會自動終止嘗試修改 A 表數據事務， 兩個事務操作都被終止，并返回下面錯誤信息。
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

查看當前運行的所有事務

mysql> SELECT * FROM information_schema.INNODB_TRX\G
*************************** 1. row ***************************
? ? ? ? ? ? ? ? ? ? trx_id: 45900
? ? ? ? ? ? ? ? ?trx_state: ROLLING BACK
? ? ? ? ? ? ? ?trx_started: 2018-04-09 10:24:38
? ? ?trx_requested_lock_id: NULL
? ? ? ? ? trx_wait_started: NULL
? ? ? ? ? ? ? ? trx_weight: 30687
? ? ? ?trx_mysql_thread_id: 0
? ? ? ? ? ? ? ? ?trx_query: NULL
? ? ? ?trx_operation_state: NULL
? ? ? ? ?trx_tables_in_use: 0
? ? ? ? ?trx_tables_locked: 0
? ? ? ? ? trx_lock_structs: 1
? ? ?trx_lock_memory_bytes: 320
? ? ? ? ? ?trx_rows_locked: 1
? ? ? ? ?trx_rows_modified: 30686
? ?trx_concurrency_tickets: 0
? ? ? ?trx_isolation_level: REPEATABLE READ
? ? ? ? ?trx_unique_checks: 1
? ? trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
?trx_adaptive_hash_latched: 0
?trx_adaptive_hash_timeout: 10000
1 row in set (0.00 sec)
關注事務所在線程ID:?
trx_mysql_thread_id: 0?
線程0的事務沒有commit導致死鎖，執行：
kill 0; ? ?//強制關閉線程和事務
執行結果：ERROR 1094 (HY000): Unknown thread id: 0

發現并沒有解決問題，繼續。

MYSQL中如何強制終止一條語句的執行

KILL命令的語法格式如下：KILL [CONNECTION | QUERY] thread_id

步驟如下：

1、KILL允許自選的CONNECTION或QUERY修改符：KILL CONNECTION與不含修改符的KILL一樣：它會終止與給定的thread_id有關的連接。

2、KILL QUERY會終止連接當前正在執行的語句，但是會保持連接的原狀。

3、如果您擁有PROCESS權限，則您可以查看所有線程。

4、如果您擁有超級管理員權限，您可以終止所有線程和語句。否則，您只能查看和終止您自己的線程和語句。

5、您也可以使用mysqladmin processlist和mysqladmin kill命令來檢查和終止線程。

首先登錄mysql，然后使用： show processlist; 查看當前mysql中各個線程狀態。

以上顯示出當前正在執行的sql語句列表，找到消耗資源最大的那條語句對應的id.

然后運行kill命令，命令格式如下：

[sql] view plain copy
kill id; ?
- 示例: ?
kill 8358 ?

避免死鎖的方法

InnoDB給MySQL提供了具有提交，回滾和崩潰恢復能力的事務安全（ACID兼容）存儲引擎。InnoDB鎖定在行級并且也在SELECT語句提供非鎖定讀。這些特色增加了多用戶部署和性能。
但其行鎖的機制也帶來了產生死鎖的風險，這就需要在應用程序設計時避免死鎖的發生。以單個SQL語句組成的隱式事務來說，建議的避免死鎖的方法如下：
1.如果使用insert…select語句備份表格且數據量較大，在單獨的時間點操作，避免與其他sql語句爭奪資源，或使用select into outfile加上load data infile代替 insert…select，這樣不僅快，而且不會要求鎖定
2. 一個鎖定記錄集的事務，其操作結果集應盡量簡短，以免一次占用太多資源，與其他事務處理的記錄沖突。
3.更新或者刪除表格數據，sql語句的where條件都是主鍵或都是索引，避免兩種情況交叉，造成死鎖。對于where子句較復雜的情況，將其單獨通過sql得到后，再在更新語句中使用。
4. sql語句的嵌套表格不要太多，能拆分就拆分，避免占有資源同時等待資源，導致與其他事務沖突。
5. 對定點運行腳本的情況，避免在同一時間點運行多個對同一表進行讀寫的腳本，特別注意加鎖且操作數據量比較大的語句。
6.應用程序中增加對死鎖的判斷，如果事務意外結束，重新運行該事務，減少對功能的影響。

（六）事務的提交與回滾極死鎖檢測、處理和預防
事務的提交與回滾極死鎖檢測、處理和預防

（一）MySQL?InnoDB事務模型

（二）MySQL?InnoDB鎖模型

（三）MySQL?InnoDB非鎖定一致性讀與鎖定讀

（四）MySQL?InnoDB鎖類型及幻象讀問題

（五）MySQL?InnoDB中各類語句加鎖方式

（六）事務的提交與回滾極死鎖檢測、處理和預防

事務的提交與回滾

默認情況下，MySQL開啟自動提交，每條語句執行完成且運行無誤的情況下會被自動提交。若語句發生了錯誤，提交或回滾與具體的SQL有關。另外，還有一些語句會隱式的結束一個事務，就好比在執行這些SQL前執行了COMMIT語句。

若發生了Table?is?full錯誤?InnoDB會回滾語句。

死鎖導致InnoDB回滾整個事務。若單是發生了?lock?wait?timeout則InnoDB僅會回滾事務中等待鎖并發生超時的SQL語句。若想在此種情況下回滾整個事務，可通過同時開啟?--innodb_rollback_on_timeout選項。死鎖和鎖等待在繁忙的服務器中很常見。應用需妥善處理這些情況，盡可能在較少的記錄上持有鎖，并且鎖定的時間盡可能的短。若是通過START?TRANSACTION或BEGIN明確開啟事務，則死鎖或者鎖等待超時導致的回滾并不會關閉當前事務，后續的SQL語句仍會成為當前事務的一部分，除非使用COMMIT，ROLLBACK或者其他隱式提交事務的語句。

若沒有指定IGNORE則?duplicate-key?error會導致SQL語句回滾。row?too?long?error也會導致SQL語句回滾。其他的錯誤大多由MySQL?Server層而非InnoDB引擎層檢測，會回滾SQL語句。單挑SQL語句回滾不會釋放事務持有的鎖。

一些會隱式的結束事務的SQL，分為幾大類：定義或修改數據庫對象的DDL語句；隱式的使用或者修改mysql庫中的表的語句；事務控制與鎖定語句；數據導入語句；數據庫管理語句；復制控制語句等。具體可參考官方手冊：http://dev.mysql.com/doc/refman/5.6/en/implicit-commit.html

InnoDB中死鎖自動被檢測出，并選擇代價較小的事務進行回滾以打破死鎖。事務完全回滾后其保持的鎖被全部釋放，若是僅有單條SQL由于錯誤發生了回滾則語句保持的鎖可能不會被釋放，因為InnoDB中不保存哪條語句持有哪些鎖的信息。若事務中的select調用了存儲函數，函數中的SQL執行失敗，則該語句被回滾。

死鎖是事務型應用中的典型問題，不可消除只能盡可能避免。死鎖并不危險但頻繁出現就有問題了。應用中應做好出現死鎖導致事務回滾后的后續處理邏輯。

如何預防和處理死鎖？

對于DBA，可以通過SHOW?ENGINE?INNODB?STATUS?查看最近的死鎖信息，以輔助調整應用。另外，若想看到更加詳細的信息可開啟innodb_print_all_deadlocks?配置，這樣可以在error?log中看到所有的死鎖信息而非最近的一個（調試結束后記得關閉）。
應用中需要有死鎖發生后導致事務回滾的處理邏輯。

盡量保持事務短小精悍以避免沖突。

盡早提交事務，不要保持一個有長期未關閉事務的交互式mysql?session。

若非必要則不使用鎖定讀，若要選擇使用鎖定讀則可選擇較低的事務隔離級別如?READ?COMMITTED。

若在同一事務中修改多個表或者修改同一表中的不同行，則每次盡量按一致的順序進行操作。

為表添加合理的索引，并用explain確認SQL能否使用到合適的索引。

特殊情況下可以使用表鎖。

通過設置輔助表來序列化事務，表中只包含一行，事務在訪問其他表前必須更新該表中的行，這樣可保證事務的串行執行，避免死鎖。

不好的事務使用習慣

·?在循環中提交事務

·?使用自動提交

·?自動回滾

·?長事務

mysql中 insert …select …帶來的死鎖問題
轉載?2015年06月17日 14:51:26
7021

mysql中 insert …select …帶來的問題

當使用insert...select...進行記錄的插入時，如果select的表是innodb類型的，不論insert的表是什么類型的表，都會對select的表的紀錄進行鎖定。

對于那些從oracle遷移過來的應用，需要特別的注意，因為oracle并不存在類似的問題，所以在oracle的應用中insert...select...操作非常的常見。例如：有時候會對比較多的紀錄進行統計分析，然后將統計的中間結果插入到另外一個表，這樣的操作因為進行的非常少，所以可能并沒有設置相應的索引。如果遷移到mysql數據庫后不進行相應的調整，那么在進行這個操作期間，對需要select的表實際上是進行的全表掃描導致的所有記錄的鎖定，將會對應用的其他操作造成非常嚴重的影響。

究其主要原因，是因為mysql在實現復制的機制時和oracle是不同的，如果不進行select表的鎖定，則可能造成從數據庫在恢復期間插入結果集的不同，造成主從數據的不一致。如果不采用主從復制，關閉binlog并不能避免對select紀錄的鎖定，某些文檔中提到可以通過設置innodb_locks_unsafe_for_binlog來避免這個現象，當這個參數設置為true的時候，將不會對select的結果集加鎖，但是這樣的設置將可能帶來非常嚴重的隱患。如果使用這個binlog進行從數據庫的恢復，或者進行主數據庫的災難恢復，都將可能和主數據庫的執行效果不同。

因此，我們并不推薦通過設置這個參數來避免insert...select...導致的鎖，如果需要進行可能會掃描大量數據的insert...select操作，我們推薦使用select...into outfile和load data infile的組合來實現，這樣是不會對紀錄進行鎖定的,但是效率會下降?

參考：

mysql事務執行時間過長引起死鎖
http://blog.csdn.net/lin_credible/article/details/8541195
http://www.51testing.com/html/16/390216-838016.html
http://www.jb51.net/article/32651.htm

?————————————————?
版權聲明：本文為CSDN博主「Alex許恒」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/xuheng8600/article/details/79868122

總結

以上是生活随笔為你收集整理的解决MySQL事务未提交导致死锁报错 避免死锁的方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。