sql-server - ROW_NUMBER OVER(按日期_列排序)

Question

我想知道。我有一个复杂的查询，在 SQL Server 2005 Express 版本中运行大约需要 3 秒。

主表大约有 300k 行。

当我添加时

ROW_NUMBER() OVER (ORDER BY date_column)

需要 123 秒，而 date_column 是 datetime 列。

如果我这样做

ROW_NUMBER() OVER (ORDER BY string_title)

3 秒后再次运行。

我在datetime 列上添加了索引。不用找了。还有 123 秒。

然后我尝试了:

ROW_NUMBER() OVER (ORDER BY CAST(date_column AS int))

并且查询会在 3 秒后再次运行。

既然转换需要时间，为什么 SQL Server 会这样？？？

更新:似乎 ROW_NUMBER 根本忽略我的 WHERE 语句并为所有可用条目构建行列列表？谁能证实这一点？

这里我在 SQL Management Studio 中复制了一个可读性更好的(仍然是大量逻辑:)):

SELECT ROW_NUMBER() OVER (ORDER BY xinfobase.lid) AS row_num, *
FROM xinfobase
LEFT OUTER JOIN [xinfobasetree] ON [xinfobasetree].[lid] = [xinfobase].[xlngfolder] 
LEFT OUTER JOIN [xapptqadr] ON [xapptqadr].[lid] = [xinfobase].[xlngcontact] 
LEFT OUTER JOIN [xinfobasepvaluesdyn] ON [xinfobasepvaluesdyn].[lparentid] = [xinfobase].[lid] 
WHERE (xinfobase.xlngisdeleted=2 
AND xinfobase.xlinvalid=2) 
AND (xinfobase.xlngcurrent=1) 
AND ( (xinfobase.lownerid = 1  
       OR (SELECT COUNT(lid) 
           FROM xinfobaseacl 
           WHERE xinfobaseacl.lparentid = xinfobase.lid 
             AND xlactor IN(1,-3,-4,-230,-243,-254,-255,-256,-257,-268,-589,-5,-6,-7,-8,-675,-676,-677,-9,-10,-864,-661,-671,-913))>0 
               OR xinfobasetree.xlresponsible = 1) 
AND (xinfobase.lid IN (SELECT lparentid 
                       FROM xinfobasealt a, xinfobasetree t 
                       WHERE a.xlfolder IN(1369) 
                         AND a.xlfolder = t.lid 
                         AND dbo.sf_MatchRights(1, t.xtxtrights,'|')=1 )) ) 
AND ((SELECT COUNT(*) FROM dbo.fn_Split(cf_17,',') 
      WHERE [value] = 39)>0)

此查询对 300k 条记录需要 2-3 秒。现在，我将 ORDER BY 更改为 xinfobase.xstrtitle，然后它再次在大约 2-3 秒内运行。如果我切换到 xinfobase.dtedit(带有我刚刚添加的附加索引的日期时间列)，它需要我上面已经提到的时间。

我还尝试“作弊”，将我的语句作为 SUB SELECT 来强制他首先检索记录，然后在另一个 SQL 语句中执行 ROW_NUMBER()，同样的性能结果。

Answer 1

更新

在我仍然对解决方法感到沮丧之后，我进行了更多调查。我删除了所有现有索引并对表运行了多个 SQL 语句。事实证明，使用新的列排序顺序构建新索引并包含不同的列我解决了我的问题，并且使用 dtedit(日期时间)列进行查询也很快。

吸取的教训:更加关心您的索引和执行计划，并在您生成的软件的每次更新(新版本)时重新检查它们...

但仍然想知道为什么 CAST(datetime_column AS int) 之前速度很快