文本或 NVARCHAR(MAX) 字段的索引策略

bum*_*una 2 performance index sql-server-2005 sql-server index-tuning query-performance

我有以下查询(针对问题进行了简化)我正在尝试加快只读数据库的速度...

SELECT 
 [sysid]
,[Date]=CONVERT(CHAR, DATEADD(D, [date], '1800-12-28'),101)   
,[From]=[from_addr]   
,[To]=[to_addr]  --I'm a very long Text or NVARCHAR(MAX) Field
,[Subject]=[subject]  
,CASE WHEN [attach] = 1 THEN 'Yes' ELSE 'No' END AS 'Att'   
,[Code]=[ccode]   
,[Staff]=[staff]  
,[MatNo]=[mat_no]  
FROM dbo.[email] 
DYNAMIC WHERE CLAUSE ON ANY OF ABOVE
Run Code Online (Sandbox Code Playgroud)

我已经尝试添加一些索引,包括覆盖索引我不能包含 to_addr 的方式(作为文本或 NVARCHAR(MAX) col),并且查询优化器最终使用聚集索引,因为不包含 to_addr 字段。有什么方法可以处理这样的情况?不幸的是,我仅限于 2005 年。

编辑

尝试添加 Full_Text For to_addr 仍然进行表扫描。但是,如果我注释掉该行,它将使用索引。:(该死的文本数据!

Aar*_*and 5

为什么你认为应该使用扫描来拉回所有数据?全文索引不会真正有帮助 - 可以帮助您搜索这些列,但是如果您只是返回所有数据(对于任何种类的 WHERE 子句),那么没有读取所有数据的捷径。我能问一下为什么 a to_addr,大概被 SMTP 标准限制为 ~320 个字符(取决于你相信哪个标准),包含 > 4000 个字符的数据?

很多人认为扫描是不好的。如果需要返回大量数据,那么通常会使用聚集索引扫描。您的 where 子句可能会导致使用搜索来定位要返回的行,但在该列中的数据如此大的情况下,搜索将不起作用。您是否只是在执行计划中看到扫描并假设这一定是问题所在?

  • 查询不会奇迹般地变得更快(如果您每行提取 50,000 个字符,源数据类型是什么并不重要),但是您会在许多其他领域获得收益,例如您可以与 VARCHAR( MAX) 就像一等公民,而不是 TEXT 的所有限制,当然,您的架构将得到支持(TEXT/NTEXT/IMAGE 最终将从 SQL Server 中删除)。 (3认同)