同一查询有不同的查询计划!
可能的重复:
SP sql server 是如何发生的
你好,我得到了一些奇怪的东西。我运行了这个sql:
SELECT Id , GameTypeId , PlayerId , BetAmount , Profit ,
DateAndTime
FROM Results
WHERE DateAndTime >= DATEADD (DAY , -1 , SYSDATETIME ())
AND
DateAndTime < SYSDATETIME ()
ORDER BY DateAndTime ASC;
我在日期列上有非聚集索引 返回的实际行数是 表中 1600016 行中的 672 行。 (估计的行是1)
之后我运行了这个sql:
declare @d DATETIME2(7)
set @d = DATEADD (DAY , -1 , SYSDATETIME ())
declare @d2 DATETIME2(7)
set @d2 = SYSDATETIME ()
SELECT Id , GameTypeId , PlayerId , BetAmount , Profit ,
DateAndTime FROM Results
WHERE DateAndTime >= @d
AND
DateAndTime < @d2
ORDER BY DateAndTime ASC;
并且实际的执行计划是TABLE SCNE!返回的实际行数是 表中 1600016 行中的 672 行。 (估计行数为 144000 r0ws)
有人知道这里发生了什么吗?!?!?
Possible Duplicate:
how that happen SP sql server
hello, I get something weird. i ran this sql:
SELECT Id , GameTypeId , PlayerId , BetAmount , Profit ,
DateAndTime
FROM Results
WHERE DateAndTime >= DATEADD (DAY , -1 , SYSDATETIME ())
AND
DateAndTime < SYSDATETIME ()
ORDER BY DateAndTime ASC;
i have noncluster index on the date column
and the actual number of rows that return is
672 row from 1600016 rows in the table. (the estimated row was 1)
after that i ran this sql:
declare @d DATETIME2(7)
set @d = DATEADD (DAY , -1 , SYSDATETIME ())
declare @d2 DATETIME2(7)
set @d2 = SYSDATETIME ()
SELECT Id , GameTypeId , PlayerId , BetAmount , Profit ,
DateAndTime FROM Results
WHERE DateAndTime >= @d
AND
DateAndTime < @d2
ORDER BY DateAndTime ASC;
and the actual execution plan was TABLE SCANE !!! and the actual number of rows that return is
672 row from 1600016 rows in the table. (the estimated row was 144000 r0ws)
some 1 know what happend here ?!?!?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你确定你没有搞乱执行计划吗?快速浏览一下 sql,我就会假设第一个查询需要表扫描。我将此归因于这样一个事实:您的 where 子句中有一个计算 (DATEADD),需要对每一行进行计算。当尝试编写高性能查询时,这是需要注意的事情。
Are you sure that you haven't muddle the execution plans. I would have assumed from a quick glance at the sql that the first query would require a table scan. I would attribute this to the fact that you have a calculation (DATEADD) in your where clause that would need to be evaluated on every row. This is something to wacth out for when trying to write performant queries.