現(xiàn)在mysql中有數(shù)據(jù)33.8w的數(shù)據(jù)，然后做查詢和更新或插入操作，速度很慢，基本100條數(shù)據(jù)就要1.68s。好慢啊，我要測(cè)試一下，到底慢在哪？能不能提高點(diǎn)速度？

參考一篇博文：http://blog.csdn.net/clh604/article/details/19608869#0-tsina-1-37035-397232819ff9a47a7b7e80a40613cfe1?，F(xiàn)在是2015.06.15 09:59。我要開始了。

1、首先我要在數(shù)據(jù)庫(kù)中插入50w的數(shù)據(jù)。

剛開始速度還是很快的，當(dāng)數(shù)據(jù)庫(kù)中有2w多數(shù)據(jù)時(shí)，插入速度明顯變慢，插入1000條，大約需要十幾二十秒?，F(xiàn)在數(shù)據(jù)庫(kù)中大約有4w數(shù)據(jù)，插入1000條，大約需要二三十秒。這個(gè)速度正常嗎？程序是同事的，用了SSH框架，不用手動(dòng)建表，有影響嗎？不是吧，如果速度維持在30s、1000條，還需要3個(gè)小時(shí)，才能把數(shù)據(jù)插完。現(xiàn)在數(shù)據(jù)庫(kù)中有14.7w，插入1000條大概2分半。

插入前還要根據(jù)標(biāo)題檢查是否有重復(fù)的，如果有重復(fù)的就從數(shù)據(jù)庫(kù)中查詢出來(lái)，然后合并，更新，如果沒有就插入。

不是吧，我將插入數(shù)據(jù)庫(kù)的程序改為了最簡(jiǎn)單的jdbc，參考博文：http://www.askmaclean.com/archives/java-jdbc-batch-update-optimization.html。用PreparedStatement+addBatch+executeBatch，9s中插入了13.5w條。難道用框架，效率會(huì)受這么大的影響？？不到10分鐘已經(jīng)導(dǎo)入了50w數(shù)據(jù)了。

將用SSH的程序去掉查詢，只有插入，速度大概為1000條三四秒鐘?，F(xiàn)在已經(jīng)6w了，速度沒有降低。已經(jīng)10.3w了，速度沒有變慢?？磥?lái)第一次測(cè)試時(shí)，速度變慢是因?yàn)椴樵儭?/p>

2、下面測(cè)試查詢的速度。(數(shù)據(jù)庫(kù)中有54.6w數(shù)據(jù))

比較根據(jù)id查詢和根據(jù)沒有建索引的普通字段查詢速度的差別。

比較批量查詢和單獨(dú)查詢的差別。

根據(jù)id查詢1000次，花費(fèi)時(shí)間：14s。好長(zhǎng)啊。先保存下，要下班了。現(xiàn)在是2015年6月16日 09:51，繼續(xù)。

看來(lái)昨天的14s還算正常的。今天根據(jù)title查，title是沒有建索引的，查了10條，用了大概60秒。相差3750倍！！好吧，我知道我的程序慢在哪了。

上面使用普通的jdbc查詢的，下面用SSH框架的程序測(cè)一測(cè)，用的數(shù)據(jù)庫(kù)中有348000數(shù)據(jù)。

根據(jù)id查詢1000次，竟然消耗時(shí)間：70538ms。查詢比純jdbc慢5倍，插入慢3-4倍。根據(jù)title就不測(cè)了，還是測(cè)測(cè)吧，查需10條，消耗時(shí)間：121825ms。

下面我要測(cè)測(cè)批量查詢是不是會(huì)好點(diǎn)。

我都驚了！根據(jù)id批量查詢1000次，就是用in集合，消耗時(shí)間：2996ms。好快啊，參考：http://stackoverflow.com/questions/9853197/jdbc-batch-query-for-high-performance。

根據(jù)title查詢10次，消耗時(shí)間：5745ms，查詢50次，消耗時(shí)間：6485ms，100次，消耗時(shí)間：6624ms，1000次，消耗時(shí)間：6155ms。怎么沒差別啊，是不是哪錯(cuò)了？幾次查詢之間會(huì)有影響嗎？我不明白。

用SSH框架的程序測(cè)，數(shù)據(jù)庫(kù)中34.8w，根據(jù)id一次查詢1000條，消耗時(shí)間：17083ms。根據(jù)title查詢10條，消耗時(shí)間：13182ms；50條，消耗時(shí)間：12655ms；100條，消耗時(shí)間：13682ms；500條，消耗時(shí)間：17317ms；1000條，消耗時(shí)間：21314ms。差別也不大。

到這就測(cè)的差不多了，下面總結(jié)下，要不估計(jì)只有現(xiàn)在的我能看懂了。

插入操作

純jdbc

1000條/1秒；50w數(shù)據(jù)大約10分鐘，速度穩(wěn)定。

SSH框架

1000條/3~4秒；50w數(shù)據(jù)大約30分鐘，速度穩(wěn)定。

多次單條查詢

根據(jù)id查詢

根據(jù)title查詢(無(wú)索引)

純jdbc(數(shù)據(jù)庫(kù)中有54.6w數(shù)據(jù))

1000次/14秒

10次/60秒

SSH框架(數(shù)據(jù)庫(kù)中34.8w)

1000次/70秒

10次/12秒

in語(yǔ)句批量查詢

根據(jù)id查詢

根據(jù)title查詢(無(wú)索引)

純jdbc(數(shù)據(jù)庫(kù)中有54.6w數(shù)據(jù))

1000條/3秒

1000-10條/6秒

SSH框架(數(shù)據(jù)庫(kù)中34.8w)

1000條/17秒

10條/13秒；500條/17秒；1000條/21秒

結(jié)論：純jdbc比用框架快3~5倍；插入速度不會(huì)因?yàn)閿?shù)據(jù)量增多而變慢；查詢時(shí)盡量一批批的查，不要一條條的查。

現(xiàn)在要去改我的程序了，現(xiàn)在插入100條，大約2分鐘。

今天不想測(cè)了，先到這吧。

修改了程序，沒有大動(dòng)，只將原來(lái)一條一條的查詢，改為了一批一批的查詢，速度明顯快了，而且不會(huì)隨著數(shù)據(jù)量變化而變化，現(xiàn)在速度是1000條3秒，不錯(cuò)不錯(cuò)。