解決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 …帶來的死鎖問題