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