可能是因为多增加了一个2 set操作吧,每次set的时候都要去比较下是低几个问号.所以这样一来就等于是50万*2*2次操作了

解决方案 »

  1.   

    也不是死机,就是结果一直都出不来。sqlserver的cpu 占用率到了90%
      

  2.   

    看来没有人回答了,感谢大家的捧场。
    这个应该是一个典型的JDBC问题,正如我问题所说,在数据有50多万条的情况下,用preparedstatement语句传参数运行sqlserver会长时间的占用cpu达到90%以上,且不出结果。当我把数据减到小于1万条时,运行正常。而另人奇怪的还在于在数据有50多万条的情况下,用jdbc:odbc进行连接时,直接把参数写进语句执行时,情况正常。传参数执行却错误
    在我又用microsoft:jdbc进行连接时,无论直接把参数写进语句执行还是穿参数运行,都会长时间的占用cpu达到90%以上,且不出结果。
    最后我只有在sqlserver中写了一个存储过程,语句相同。通过程序调用。运行正常。
    所以我在想:因为jdbc的机制是将sql语句“翻译”成数据库能识别的语句。是不是在microsoft:jdbc和jdbc:odbc中对该语句的“解释”是否存在缺陷?本贴中午结,如果那位还有什么想法欢迎继续发表。
      

  3.   

    >>k1.id有clustered index,它是主键。这里有问题吗?
    很慢的时候,你用DBCC MEMUSAGE看看然后你把它改成non clustered index再试试用DBCC MEMUSAGE看看给我结果,我再替你分