數據庫和mysql綁定死了（mysql什麼時候會造成數據庫死鎖）

本文目錄一覽：

• 1、使用MySQL數據庫，都有哪些情況易出現死鎖的情況？
• 2、用sql語句，怎麼解決mysql數據庫死鎖
• 3、數據庫mysql用着用着死掉了怎麼辦
• 4、急求解決！！gridview綁定MySQL數據庫時綁定出錯，大神們幫忙啊。

使用MySQL數據庫，都有哪些情況易出現死鎖的情況？

在老版本的MySQL 3.22中，MySQL的單表限大小為4GB，當時的MySQL的存儲引擎還是ISAM存儲引擎。但是，當出現MyISAM存儲引擎之後，也就是從MySQL 3.23開始，MySQL單表最大限制就已經擴大到了64PB了（官方文檔顯示）。也就是說，從目前的技術環境來看，MySQL數據庫的MyISAM存儲 引擎單表大小限制已經不是有MySQL數據庫本身來決定，而是由所在主機的OS上面的文件系統來決定了。

而MySQL另外一個最流行的存儲引擎之一Innodb存儲數據的策略是分為兩種的，一種是共享表空間存儲方式，還有一種是獨享表空間存儲方式。

當使用共享表空間存儲方式的時候，Innodb的所有數據保存在一個單獨的表空間裏面，而這個表空間可以由很多個文件組成，一個表可以跨多個文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。從Innodb的官方文檔中可以看到，其表空間的最大限制為64TB，也就是說，Innodb的單 表限制基本上也在64TB左右了，當然這個大小是包括這個表的所有索引等其他相關數據。

而當使用獨享表空間來存放Innodb的表的時候，每個表的數據以一個單獨的文件來存放，這個時候的單表限制，又變成文件系統的大小限制了。

用sql語句，怎麼解決mysql數據庫死鎖

MySQL死鎖問題的相關知識是本文我們主要要介紹的內容，接下來我們就來一一介紹這部分內容，希望能夠對您有所幫助。

1、MySQL常用存儲引擎的鎖機制

MyISAM和MEMORY採用表級鎖(table-level locking)

BDB採用頁面鎖(page-level locking)或表級鎖，默認為頁面鎖

InnoDB支持行級鎖(row-level locking)和表級鎖，默認為行級鎖

2、各種鎖特點

表級鎖：開銷小，加鎖快;不會出現死鎖;鎖定粒度大，發生鎖衝突的概率最高，並發度最低

行級鎖：開銷大，加鎖慢;會出現死鎖;鎖定粒度最小，發生鎖衝突的概率最低，並發度也最高

頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間，並發度一般

3、各種鎖的適用場景

表級鎖更適合於以查詢為主，只有少量按索引條件更新數據的應用，如Web應用

行級鎖則更適合於有大量按索引條件並發更新數據，同時又有並發查詢的應用，如一些在線事務處理系統

4、死鎖

是指兩個或兩個以上的進程在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。

表級鎖不會產生死鎖。所以解決死鎖主要還是針對於最常用的InnoDB。

5、死鎖舉例分析

在MySQL中，行級鎖並不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引;如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。

在UPDATE、DELETE操作時，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking。

例如，一個表db。tab_test，結構如下：

id：主鍵;

state：狀態;

time：時間;

索引：idx_1(state，time)

出現死鎖日誌如下：

?***(1) TRANSACTION:

?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read

?mysql tables in use 1, locked 1

?LOCK WAIT 3 lock struct(s), heap size 320

?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update

?update tab_test set state=1064,time=now() where state=1061 and time date_sub(now(), INTERVAL 30 minute) (任務1的sql語句)

?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任務1等待的索引記錄)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0

?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;

?*** (2) TRANSACTION:

?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499

?mysql tables in use 1, locked 1

?3 lock struct(s), heap size 320, undo log entries 1

?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任務2的sql語句)

?*** (2) HOLDS THE LOCK(S): (任務2已獲得的鎖)

?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap

?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0

?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 75706c6f6164666972652e636f6d2f6 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;

?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任務2等待的鎖)

?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting

?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0

?0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;;

?*** WE ROLL BACK TRANSACTION (1)

?(回滾了任務1，以解除死鎖)

原因分析：

當「update tab_test set state=1064,time=now() where state=1061 and time date_sub(now(), INTERVAL 30 minute)」執行時，MySQL會使用idx_1索引，因此首先鎖定相關的索引記錄，因為idx_1是非主鍵索引，為執行該語句，MySQL還會鎖定主鍵索引。

假設「update tab_test set state=1067,time=now () where id in (9921180)」幾乎同時執行時，本語句首先鎖定主鍵索引，由於需要更新state的值，所以還需要鎖定idx_1的某些索引記錄。

這樣第一條語句鎖定了idx_1的記錄，等待主鍵索引，而第二條語句則鎖定了主鍵索引記錄，而等待idx_1的記錄，這樣死鎖就產生了。

6、解決辦法

拆分第一條sql，先查出符合條件的主鍵值，再按照主鍵更新記錄：

?select id from tab_test where state=1061 and time date_sub(now(), INTERVAL 30 minute);

?update tab_test state=1064,time=now() where id in(……);

數據庫mysql用着用着死掉了怎麼辦

1. 檢查一下MYSQL是否已經正確安裝並且可以正常啟動使用；

2. 檢查一下你的PHP版本，如果是5.2的話，需要將php目錄下的libmysql.dll、php5ts.dll、libmcrypt.dll三個文件複製到WINDOWS目錄下的SYSTEM32下；

3. 在1和2的基礎上重啟WEB SERVER

急求解決！！gridview綁定MySQL數據庫時綁定出錯，大神們幫忙啊。

如果其他和數據庫的選項也有問題，設置找到安裝包選擇更新，看看你的數據庫相關組件安裝沒