2
持续扫描需要0秒或2-3分钟
像下面这样的查询(保证不会返回任何行)在我们的其中一台服务器上花费了0到160秒的时间: select col1, col2, col3 from tab1 where 0 = 1 两周前,这种情况每隔48小时发生了六次。上周,同一查询花费了约0秒。我有应用程序SQL的日志,但尚未发现任何可疑对象。此外,我认为顶级0/0 = 1的类型查询从未命中数据页,因此它应该能够抵抗行/页/表级数据锁吗?任何(已知)SQL都不会涉及该架构。 由于问题不一致,并且服务器承受的负载非常重,因此我想在附加SQL事件探查器之前了解发生的情况的理论。在这些延迟期间,其他查询可以正常运行。应用程序中的一个已知问题是大量动态创建的SQL查询-在48小时内大约有200k唯一查询,总共850k(记录的)查询,这会引起这样的问题吗? 该服务器运行SQL Server 2005标准版,96 GB RAM,SAN上的磁盘和4个CPU / 16核。数据库文件和文件组已经过优化,应该没有问题(但是我们正在分别研究)。 任何在哪里看的指针都将不胜感激。 编辑:完美!重播查询以添加执行计划,这花了1分钟35秒。这是执行计划和显示查询持续时间的屏幕截图: 编辑2:统计第二次运行的时间详细信息。现在似乎一直很慢,因此我们将附加探查器和perfmon: SQL Server Execution Times: CPU time = 0 ms, elapsed time = 97402 ms. SQL Server parse and compile time: CPU time = 0 ms, …