不鎖怕出事，鎖了又怕鎖死了！！！
資料庫由於資料儲存速度快，資料穩定，結構化的特性，被廣泛用作資料儲存，並成為最重要，最常見的方式！
資料庫從20世紀50年代誕生伊始，就因為支援事務的特性得到大力的發展，最終各種資料庫諸如oracle，sybase，mysql等關係型資料庫百花齊放，既然資料庫是因為事務而生，那麼事務的特性又是哪些呢？
簡而言之就是acid（原子性，一致性，隔離性，永續性）！而為了保持資料的一致性，資料庫都有了乙個操作叫做加鎖！有表級鎖，行級鎖，頁面鎖！
死鎖就是說兩個執行緒在爭同乙個資源，然後互不相讓，導致鎖死的情況（比如兩個人從兩端走上獨木橋，然後卡死在橋中間）！
回到問題本身，資料庫在什麼時候會產生死鎖呢？
1，情況一:我中有你，你中有我！
事務一:兩個操作update a;update b;
事務二:兩個操作update b;update a;
執行緒一執行事務一到一半的時候，鎖了a想要獲得b的鎖，與此同時事務二執行到了鎖b，想要獲得鎖a的時候，因為互相都想要對方擁有的鎖，而導致死鎖！
2，情況二:吃著碗裡的，看著鍋裡的！
a執行緒先查詢了一條記錄（使用了共享鎖），與此同時b執行緒正要修改這條記錄（使用了獨佔鎖），然後a執行緒突然想修改這條記錄了，怎麼辦呢？公升級鎖。。
而b執行緒想要降級為共享鎖，必須要等到a執行緒釋放掉共享鎖，這樣就形成了死鎖！
可以看到這個過程中是a佔著共享鎖想要公升級，b佔著獨佔鎖想要降級，然後卡死！
3，牽一髮而動全身！
乙個表結構，必須要有適當的索引等優化手段，如果在執行事務的時候，沒有加索引條件甚至沒有任何條件，那麼將執行全表掃瞄，如果是多個事務在操作，很容易就發生了阻塞和死鎖！所以欄位加索引非常重要！！
資料庫死鎖的解決方案。
1）以固定的順序訪問表和行。即按順序申請鎖，這樣就不會造成互相等待的場面。
2）大事務拆小。大事務更傾向於死鎖，如果業務允許，將大事務拆小。
3）在同乙個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖概率。
4）降低隔離級別。如果業務允許，將隔離級別調低也是較好的選擇，比如將隔離級別從rr調整為rc，可以避免掉很多因為gap鎖造成的死鎖。
5）為表新增合理的索引。如果不走索引將會為表的每一行記錄新增上鎖，死鎖的概率大大增大。
使用n**icat測試學習:
首先使用set autocommit = 0;(取消自動提交,則當執行語句commit或者rollback執行提交事務或者回滾)
查詢 正在執行的事務：
select * from information_schema.innodb_trx；
可以使用mysql命令：kill 執行緒id 殺掉執行緒
查詢mysql資料庫中還可以使用:
檢視正在鎖的事務
select * from information_schema.innodb_locks;
檢視等待鎖的事務
select * from information_schema.innodb_lock_waits;
查詢mysql資料庫中存在的程序
select * from information_schema.`processlist`(show processlist;)
關於Oracle 資料庫死鎖 轉
一 資料庫死鎖的現象 程式在執行的過程中，點選確定或儲存按鈕，程式沒有響應，也沒有出現報錯。二 死鎖的原理 當對於資料庫某個表的某一列做更新或刪除等操作，執行完畢後該條語句不提 交，另一條對於這一列資料做更新操作的語句在執行的時候就會處於等待狀態，此時的現象是這條語句一直在執行，但一直沒有執行成功，...
資料庫死鎖
1.死鎖的概念 死鎖是程序死鎖的簡稱，是由dijkstra於1965年研究銀行家演算法時首先提出來的。它是計算機作業系統乃至併發程式設計中最難處理的問題之一。實際上，死鎖問題不僅在計算機系統中存在，在我們日常生活中它也廣泛存在。我們先看看這樣乙個生活中的例子 在一條河上有一座橋，橋面較窄，只能容納一...
資料庫死鎖
資料庫在進行insert，update，delete這些更新操作的時候為了保證資料一致性都會使用排他鎖。乙個事務裡進行update操作，在事務結束之前 commit or rollback 排他鎖不會被釋放。因此在乙個事務裡update多條資料的時候執行順序就尤為重要，兩個併發事務中更新操作的執行順...