现在mysql中有数据33.8w的数据，然后做查询和更新或插入操作，速度很慢，基本100条数据就要1.68s。好慢啊，我要测试一下，到底慢在哪？能不能提高点速度？

参考一篇博文：http://blog.csdn.net/clh604/article/details/19608869#0-tsina-1-37035-397232819ff9a47a7b7e80a40613cfe1。现在是2015.06.15 09:59。我要开始了。

1、首先我要在数据库中插入50w的数据。

刚开始速度还是很快的，当数据库中有2w多数据时，插入速度明显变慢，插入1000条，大约需要十几二十秒。现在数据库中大约有4w数据，插入1000条，大约需要二三十秒。这个速度正常吗？程序是同事的，用了SSH框架，不用手动建表，有影响吗？不是吧，如果速度维持在30s、1000条，还需要3个小时，才能把数据插完。现在数据库中有14.7w，插入1000条大概2分半。

插入前还要根据标题检查是否有重复的，如果有重复的就从数据库中查询出来，然后合并，更新，如果没有就插入。

不是吧，我将插入数据库的程序改为了最简单的jdbc，参考博文：http://www.askmaclean.com/archives/java-jdbc-batch-update-optimization.html。用PreparedStatement+addBatch+executeBatch，9s中插入了13.5w条。难道用框架，效率会受这么大的影响？？不到10分钟已经导入了50w数据了。

将用SSH的程序去掉查询，只有插入，速度大概为1000条三四秒钟。现在已经6w了，速度没有降低。已经10.3w了，速度没有变慢。看来第一次测试时，速度变慢是因为查询。

2、下面测试查询的速度。(数据库中有54.6w数据)

比较根据id查询和根据没有建索引的普通字段查询速度的差别。

比较批量查询和单独查询的差别。

根据id查询1000次，花费时间：14s。好长啊。先保存下，要下班了。现在是2015年6月16日 09:51，继续。

看来昨天的14s还算正常的。今天根据title查，title是没有建索引的，查了10条，用了大概60秒。相差3750倍！！好吧，我知道我的程序慢在哪了。

上面使用普通的jdbc查询的，下面用SSH框架的程序测一测，用的数据库中有348000数据。

根据id查询1000次，竟然消耗时间：70538ms。查询比纯jdbc慢5倍，插入慢3-4倍。根据title就不测了，还是测测吧，查需10条，消耗时间：121825ms。

下面我要测测批量查询是不是会好点。

我都惊了！根据id批量查询1000次，就是用in集合，消耗时间：2996ms。好快啊，参考：http://stackoverflow.com/questions/9853197/jdbc-batch-query-for-high-performance。

根据title查询10次，消耗时间：5745ms，查询50次，消耗时间：6485ms，100次，消耗时间：6624ms，1000次，消耗时间：6155ms。怎么没差别啊，是不是哪错了？几次查询之间会有影响吗？我不明白。

用SSH框架的程序测，数据库中34.8w，根据id一次查询1000条，消耗时间：17083ms。根据title查询10条，消耗时间：13182ms；50条，消耗时间：12655ms；100条，消耗时间：13682ms；500条，消耗时间：17317ms；1000条，消耗时间：21314ms。差别也不大。

到这就测的差不多了，下面总结下，要不估计只有现在的我能看懂了。

插入操作

纯jdbc

1000条/1秒；50w数据大约10分钟，速度稳定。

SSH框架

1000条/3~4秒；50w数据大约30分钟，速度稳定。

多次单条查询

根据id查询

根据title查询(无索引)

纯jdbc(数据库中有54.6w数据)

1000次/14秒

10次/60秒

SSH框架(数据库中34.8w)

1000次/70秒

10次/12秒

in语句批量查询

根据id查询

根据title查询(无索引)

纯jdbc(数据库中有54.6w数据)

1000条/3秒

1000-10条/6秒

SSH框架(数据库中34.8w)

1000条/17秒

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

结论：纯jdbc比用框架快3~5倍；插入速度不会因为数据量增多而变慢；查询时尽量一批批的查，不要一条条的查。

现在要去改我的程序了，现在插入100条，大约2分钟。

今天不想测了，先到这吧。

修改了程序，没有大动，只将原来一条一条的查询，改为了一批一批的查询，速度明显快了，而且不会随着数据量变化而变化，现在速度是1000条3秒，不错不错。