15 个解决方案
#1
第1次需要SQL分析你的语句,生成查询执行计划,保存在高速缓冲。
第2-N次直接使用第1次生成的查询执行计划。
第2-N次直接使用第1次生成的查询执行计划。
#2
SQL会在第一次查询出结果集后将结果保存至内存中,下次查询的时候就可以直接从结果从内存中取出
#3
数据库连接的过程需要资源。可以试试:在应用程序开始的时候建立连接,一直保持到应用程序退出。
这种方式在大型应用中当然存在问题,但比较方便。也可以考虑使用数据库连接池技术,比较正宗的解决办法。
这种方式在大型应用中当然存在问题,但比较方便。也可以考虑使用数据库连接池技术,比较正宗的解决办法。
#4
按照楼主所说的时间,应该不是SQL自身问题。邻居们所言的时间差距应该不会到这种数量级
#5
楼子说的对
#6
1楼说的比较有道理`。学习
#7
这个问题哪里叫奇怪嘛
#8
那如何解决第一次耗时太长的问题。
#9
可以把表pin在内存里,这样第一次执行要快一点;基本上,第一次查询要快,主要在语句优化层面。
#10
如下几个方面会使第二次速度加快:
1)SQL的执行计划已经生成并优化,第二次运行时可以直接使用。(这一步是解析SQL过程中最慢的)
2)SQL引擎从磁盘读数据不是一次读一条,而是一次读一块,里面会包括很多相邻的记录
第二次执行时,有很大的可能性这些数据已经被读到内存里面,可以直接使用。(I/O是最慢的!)
3)如2楼所说,建立数据库连接的过程也非常耗资源。所以,最好能重用数据库连接。
LZ说的4.5秒和0.3秒的差别是完全可能的。这么大的速度提升应该是由于上面的第二个原因,也许还包括第三个原因。
1)SQL的执行计划已经生成并优化,第二次运行时可以直接使用。(这一步是解析SQL过程中最慢的)
2)SQL引擎从磁盘读数据不是一次读一条,而是一次读一块,里面会包括很多相邻的记录
第二次执行时,有很大的可能性这些数据已经被读到内存里面,可以直接使用。(I/O是最慢的!)
3)如2楼所说,建立数据库连接的过程也非常耗资源。所以,最好能重用数据库连接。
LZ说的4.5秒和0.3秒的差别是完全可能的。这么大的速度提升应该是由于上面的第二个原因,也许还包括第三个原因。
#11
楼主可以把你在应用程序中执行的查询语句放到查询分析器中执行两次看看时间差异。
虽然SQL执行计划的生成及优化需要些时间,但我不相信一个正常执行需要0.3秒的脚本,分析优化SQLServer需要4秒。
虽然SQL执行计划的生成及优化需要些时间,但我不相信一个正常执行需要0.3秒的脚本,分析优化SQLServer需要4秒。
#12
第一嘛总是有点不习惯的,大家都生疏嘛.习惯了就好了.
#13
第一次查询把结果存在缓存中,需要时间.
第二次直接从缓存中取,速度当然快了.
但是如果你查询后10,20分中不动,再查询,仍然时间长,因为缓存中的数据没了.
第二次直接从缓存中取,速度当然快了.
但是如果你查询后10,20分中不动,再查询,仍然时间长,因为缓存中的数据没了.
#14
不知道楼主有没有将应用中的查询语句联同相关参数放到查询分析器中验证执行时间?
#15
?
#1
第1次需要SQL分析你的语句,生成查询执行计划,保存在高速缓冲。
第2-N次直接使用第1次生成的查询执行计划。
第2-N次直接使用第1次生成的查询执行计划。
#2
SQL会在第一次查询出结果集后将结果保存至内存中,下次查询的时候就可以直接从结果从内存中取出
#3
数据库连接的过程需要资源。可以试试:在应用程序开始的时候建立连接,一直保持到应用程序退出。
这种方式在大型应用中当然存在问题,但比较方便。也可以考虑使用数据库连接池技术,比较正宗的解决办法。
这种方式在大型应用中当然存在问题,但比较方便。也可以考虑使用数据库连接池技术,比较正宗的解决办法。
#4
按照楼主所说的时间,应该不是SQL自身问题。邻居们所言的时间差距应该不会到这种数量级
#5
楼子说的对
#6
1楼说的比较有道理`。学习
#7
这个问题哪里叫奇怪嘛
#8
那如何解决第一次耗时太长的问题。
#9
可以把表pin在内存里,这样第一次执行要快一点;基本上,第一次查询要快,主要在语句优化层面。
#10
如下几个方面会使第二次速度加快:
1)SQL的执行计划已经生成并优化,第二次运行时可以直接使用。(这一步是解析SQL过程中最慢的)
2)SQL引擎从磁盘读数据不是一次读一条,而是一次读一块,里面会包括很多相邻的记录
第二次执行时,有很大的可能性这些数据已经被读到内存里面,可以直接使用。(I/O是最慢的!)
3)如2楼所说,建立数据库连接的过程也非常耗资源。所以,最好能重用数据库连接。
LZ说的4.5秒和0.3秒的差别是完全可能的。这么大的速度提升应该是由于上面的第二个原因,也许还包括第三个原因。
1)SQL的执行计划已经生成并优化,第二次运行时可以直接使用。(这一步是解析SQL过程中最慢的)
2)SQL引擎从磁盘读数据不是一次读一条,而是一次读一块,里面会包括很多相邻的记录
第二次执行时,有很大的可能性这些数据已经被读到内存里面,可以直接使用。(I/O是最慢的!)
3)如2楼所说,建立数据库连接的过程也非常耗资源。所以,最好能重用数据库连接。
LZ说的4.5秒和0.3秒的差别是完全可能的。这么大的速度提升应该是由于上面的第二个原因,也许还包括第三个原因。
#11
楼主可以把你在应用程序中执行的查询语句放到查询分析器中执行两次看看时间差异。
虽然SQL执行计划的生成及优化需要些时间,但我不相信一个正常执行需要0.3秒的脚本,分析优化SQLServer需要4秒。
虽然SQL执行计划的生成及优化需要些时间,但我不相信一个正常执行需要0.3秒的脚本,分析优化SQLServer需要4秒。
#12
第一嘛总是有点不习惯的,大家都生疏嘛.习惯了就好了.
#13
第一次查询把结果存在缓存中,需要时间.
第二次直接从缓存中取,速度当然快了.
但是如果你查询后10,20分中不动,再查询,仍然时间长,因为缓存中的数据没了.
第二次直接从缓存中取,速度当然快了.
但是如果你查询后10,20分中不动,再查询,仍然时间长,因为缓存中的数据没了.
#14
不知道楼主有没有将应用中的查询语句联同相关参数放到查询分析器中验证执行时间?
#15
?