推薦：解讀MySQL中SQL的單字節(jié)注入與寬字節(jié)注入
一、單字節(jié)SQL注入 MYSQL的SQL注入已經(jīng)由來已久，以下是普遍采用的注入步驟： 1、在GET參數(shù)上加一個/*或者#（mysql專有的注釋），判斷數(shù)據(jù)庫是否是mysql，比如： http://www.xxx.com.cn/article.php?id=1607 and 1=1/* 2、猜解某表的字段數(shù)，從order by 1一

今天碰到一個mysql5數(shù)據(jù)庫的問題。就是一個標準的servlet/tomcat網(wǎng)絡應用，后臺使用mysql數(shù)據(jù)庫。問題是待機一晚上后，第二天早上第一次登錄總是失敗。察看日志發(fā)現(xiàn)如下錯誤：

“com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

Last packet sent to the server was 0 ms ago.”
 

經(jīng)過一番調研，發(fā)現(xiàn)很多人都碰到過類似問題，但網(wǎng)上令人滿意的回答并不多。mysql網(wǎng)站上的提問也很多，但并沒有正確答案；百度知道上倒是有一個近似正確的回答�，F(xiàn)將本人的解決辦法總結一下：

上述問題是由mysql5數(shù)據(jù)庫的配置引起的。mysql5將其連接的等待時間(wait_timeout)缺省為8小時。在其客戶程序中可以這樣來查看其值：

mysql﹥

mysql﹥ show global variables like 'wait_timeout';

+---------------+---------+

| Variable_name | Value |

+---------------+---------+

| wait_timeout | 28800 |

+---------------+---------+

1 row in set (0.00 sec)
 

28800 seconds，也就是8小時。

如果在wait_timeout秒期間內(nèi)，數(shù)據(jù)庫連接(java.sql.Connection)一直處于等待狀態(tài)，mysql5就將該連接關閉。這時，你的Java應用的連接池仍然合法地持有該連接的引用。當用該連接來進行數(shù)據(jù)庫操作時，就碰到上述錯誤。這解釋了為什么我的程序第二天不能登錄 的問題。

你可能會想到在tomcat的數(shù)據(jù)源配置中有沒有辦法解決？的確，在jdbc連接url的配置中，你可以附上“autoReconnect=true”，但這僅對mysql5以前的版本起作用。增加“validation query”似乎也無濟于事。

本人覺得最簡單的辦法，就是對癥下藥：既然問題是由mysql5的全局變量wait_timeout的缺省值太小引起的，我們將其改大就好了。

查看mysql5的手冊，發(fā)現(xiàn)對wait_timeout的最大值分別是24天/365天(windows/linux)。以windows為 例，假設我們要將其設為21天，我們只要修改mysql5的配置文件“my.ini”(mysql5 installation dir)，增加一行：wait_timeout=1814400

需要重新啟動mysql5。

linux系統(tǒng)配置文件：/etc/my.cnf

這樣測試顯示問題就迎刃而解了。

分享：關于Oracle與SQL Server數(shù)據(jù)庫鏡像的對比
數(shù)據(jù)庫鏡像是將數(shù)據(jù)庫事務處理從一個數(shù)據(jù)庫移動到不同環(huán)境中的另一個數(shù)據(jù)庫中。鏡像的拷貝是一個備用的拷貝，不能直接訪問，它只用在錯誤恢復的情況下。Oracle數(shù)據(jù)庫與MSSQL數(shù)據(jù)操作上有很大的不同，但是，在鏡像操作方面有類比的地方。這篇文章關于MSSQL數(shù)