Estou com a seguinte query (simplificada para questionar) estou tentando agilizar para um BD somente leitura...
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
Já tentei adicionar alguns índices incluindo índices de cobertura não consigo incluir o to_addr do jeito que está (como texto ou NVARCHAR(MAX) col), e o otimizador de consulta acaba usando o índice clusterizado porque o campo to_addr não está incluído. Quais são algumas maneiras de lidar com uma situação como esta? Infelizmente, estou limitado a 2005 sobre isso.
Editar
Tentei adicionar Full_Text For to_addr ainda faz uma varredura de tabela. No entanto, se eu comentar essa linha, ela usará o index. : (Malditos dados de texto!
Por que você acha que qualquer coisa, exceto uma varredura, deve ser usada para recuperar todos os dados? Um índice de texto completo não ajudará muito - isso ajuda a pesquisar essas colunas, mas se você estiver apenas retornando todos os dados (para qualquer variedade de cláusulas WHERE), não haverá atalho para ler todos os dados. Posso perguntar por que um
to_addr
, presumivelmente limitado a ~ 320 caracteres pelos padrões SMTP (dependendo do padrão em que você acredita), contém dados > 4.000 caracteres?Muitas pessoas pensam que uma varredura é ruim. Se você precisar retornar uma grande quantidade de dados, geralmente será usada uma varredura de índice clusterizado. Sua cláusula where pode levar a buscas sendo usadas para localizar as linhas a serem retornadas, mas uma busca não funcionará onde os dados nessa coluna são tão grandes. Você está apenas vendo uma varredura no plano de execução e assumindo que esse deve ser o problema?