最近mysql數據庫經常死掉，用命令net stop mysql命令也無法停掉，關閉Tomcat的時候，出現Waiting for N instance(s) to be deallocated 信息。查了下，大概就是程序沒有對數據庫連接釋放，導致Connection泄露了。因為用的是開元集成的平台，內部程序也不可能一下子給改掉的，就驗證一下咯。啟動Tomcat,用戶登錄系統，用netstat -ano|findstr 8000命令來查看tomcat端口占用情況，可以看到8000端口會被用戶的IP地址占用，而對應的PID是0，PID=0是什么呢，是叫System Idel Process的一個進程，這個進程是一個空閑的進程。Tomcat一直被這個進程占用，沒有釋放，時間長了用戶多了，mysql就死掉了，至於是不是程序沒有釋放連接，這個應該是沒可能，因為系統已經用了2年，這種情況出現的太少了。
看一下mysql中表的情況，表的數據長度到達了幾個G了，這種是BLOB類型的，存儲的數據過多，這樣的話是不是因為數據量太大，用戶在用的時候對數據庫進行操作，空間又不夠，互相等待，造成死鎖的問題呢？
這年頭，一定要注意備份啊，mysql要備份的東西比較多，
(1)表結構文件，MySQL\MySQL Server 5.1\data目錄下存放的就是數據庫結構，會看到相應的數據庫目錄，數據庫目錄下面有.frm文件,.myd文件，.myi文件，這些文件都是表結構的文件。
(2)表數據文件，MySQL Datafiles/ibdata1文件
(3)日志文件，MySQL\MySQL Server 5.1\data目錄下面ib_logfile0文件和ib_logfile1文件。二進制日志文件，如果你想要重新處理日志止的語句，這很有用。
你的數據庫結構沒有問題的情況下，想恢復數據，如果有（2）、（3）應該是沒有問題的，當時我只有（2），把ibdata1文件copy過去，恢復數據還是出了很多狀況，啟動系統還是不能用的，mysql日志一直提示Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files.說多了都是淚，誰讓咱是IT呢，系統壞掉了電話都要被用戶打爆的節奏，hold不住，無所不用其極的，各種搜索資料啊，最后嘗試一下大多數人的辦法，設置innodb_force_recovery參數。
innodb_force_recovery影響整個InnoDB存儲引擎的恢復狀況。默認為0，表示當需要恢復時執行所有的
innodb_force_recovery可以設置為1-6,大的數字包含前面所有數字的影響。當設置參數值大於0后，可以對表進行select,create,drop操作,但insert,update或者delete這類操作是不允許的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執行full purge操作，會導致crash。
3(SRV_FORCE_NO_TRX_UNDO):不執行事務回滾操作。
4(SRV_FORCE_NO_IBUF_MERGE):不執行插入緩沖的合並操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存儲引擎會將未提交的事務視為已提交。
6(SRV_FORCE_NO_LOG_REDO):不執行前滾的操作。
設置innodb_force_recovery=4重啟msql,再恢復成默認值（即不需要再my.ini文件時設置innodb_force_recovery參數），重啟mysql，重啟Tomcat，OK了，太驚喜了。
菜鳥一個，其中原理講的都不太清楚，經驗之談，僅供參考。
看一下mysql中表的情況，表的數據長度到達了幾個G了，這種是BLOB類型的，存儲的數據過多，這樣的話是不是因為數據量太大，用戶在用的時候對數據庫進行操作，空間又不夠，互相等待，造成死鎖的問題呢？
這年頭，一定要注意備份啊，mysql要備份的東西比較多，
(1)表結構文件，MySQL\MySQL Server 5.1\data目錄下存放的就是數據庫結構，會看到相應的數據庫目錄，數據庫目錄下面有.frm文件,.myd文件，.myi文件，這些文件都是表結構的文件。
(2)表數據文件，MySQL Datafiles/ibdata1文件
(3)日志文件，MySQL\MySQL Server 5.1\data目錄下面ib_logfile0文件和ib_logfile1文件。二進制日志文件，如果你想要重新處理日志止的語句，這很有用。
你的數據庫結構沒有問題的情況下，想恢復數據，如果有（2）、（3）應該是沒有問題的，當時我只有（2），把ibdata1文件copy過去，恢復數據還是出了很多狀況，啟動系統還是不能用的，mysql日志一直提示Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files.說多了都是淚，誰讓咱是IT呢，系統壞掉了電話都要被用戶打爆的節奏，hold不住，無所不用其極的，各種搜索資料啊，最后嘗試一下大多數人的辦法，設置innodb_force_recovery參數。
innodb_force_recovery影響整個InnoDB存儲引擎的恢復狀況。默認為0，表示當需要恢復時執行所有的
innodb_force_recovery可以設置為1-6,大的數字包含前面所有數字的影響。當設置參數值大於0后，可以對表進行select,create,drop操作,但insert,update或者delete這類操作是不允許的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執行full purge操作，會導致crash。
3(SRV_FORCE_NO_TRX_UNDO):不執行事務回滾操作。
4(SRV_FORCE_NO_IBUF_MERGE):不執行插入緩沖的合並操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存儲引擎會將未提交的事務視為已提交。
6(SRV_FORCE_NO_LOG_REDO):不執行前滾的操作。
設置innodb_force_recovery=4重啟msql,再恢復成默認值（即不需要再my.ini文件時設置innodb_force_recovery參數），重啟mysql，重啟Tomcat，OK了，太驚喜了。
菜鳥一個，其中原理講的都不太清楚，經驗之談，僅供參考。