1.注意auto_increment
mysql5.0在高并發(fā)下(每天近2億)插入單表數(shù)據(jù)出現(xiàn)了死鎖(偶現(xiàn))，查了下相關文檔，發(fā)現(xiàn)是因為采用了auto-increment的主鍵帶來的問題，造成Table級的死鎖。
原因：對于auto_increment字段，innodb會在內存里保存一個計數(shù)器用來記錄auto_increment的值，當插入一個新行數(shù)據(jù)時，就會用一個表鎖來鎖住這個計數(shù)器，所以會
造成Table級的死鎖。
在Mysql5.1服務器配置多了一個參數(shù)innodb_autoinc_lock_mode，可以設置不同的值避免這個問題。比如設為1
innodb_autoinc_lock_mode = 0
(“
traditional” lock mode)
innodb_autoinc_lock_mode = 1
(“
consecutive” lock mode)
Mysql5.1默認
innodb_autoinc_lock_mode = 2
(“
interleaved” lock mode)
2.注意數(shù)據(jù)庫連接
應用中偶現(xiàn)性錯誤：
Last packet sent to the server was 8202
ms ago.; nested exception is
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link
failure
連接池中的connection無法連接到數(shù)據(jù)庫,原因是池中的空閑conn連接db超時，而c3p0 pool本身不知道。
查了下Mysql5.0文檔，默認的等待時間是8小時——show global variables like 'wait_timeout'
但是該服務器的時間又不太合理。
還是覺得在jdbc pool上做調整，比如在jdbc.url加入一個參數(shù)autoReconnect=true。可以解決。
3.重視jdbc連接池配置
高并發(fā)下，4個連接池，每個100個最大連接。高峰期出行can not get a connection的錯誤。詢問過DBA，mysql數(shù)據(jù)庫高峰期最大連接近300。
理論上連接池還是夠的。但仍然爆掉。推測原因可能出在DBCP連接池有些連接使用后一直被占著，沒有釋放回連接池。
據(jù)此，修改DBCP配置，加入2個參數(shù)：
removeAbandoned=true
removeAbandonedTimeout==200
問題不再出現(xiàn)。
4.
字符集文件
mysql 數(shù)據(jù)庫目錄下面有個文件db.opt ，記錄了db的字符集。如果你是通過alter databases(schema) 命令更改的數(shù)據(jù)庫默認屬性，那么現(xiàn)有的表的默認字符集和排序規(guī)則不受影響。新建的表即使不指定字符集，仍采用數(shù)據(jù)庫的字符集。