Rendimiento de la población de índices de texto completo en una vista indizada de SQL 2005

Question

He creado una vista indizada:

CREATE VIEW LogValueTexts WITH SCHEMABINDING AS
SELECT ISNULL(LRVS_SLOG_ID*256+LRVS_IDX,0) AS ID,LRVS_VALUE AS Value
FROM dbo.LRVS_LogRecordedValues WHERE LEN(LRVS_VALUE)>4

CREATE UNIQUE CLUSTERED INDEX IX_LogValueTexts ON LogValueTexts (ID)

En SQL 2005 Standard SP3, se tarda una eternidad en rellenar un índice de texto completo en esa vista porque la indexación de texto completo ejecuta la siguiente consulta para cada fila en la vista:

SELECT COLUMN FULLTEXTALL FROM[dbo].[LogValueTexts] WHERE COLUMN FULLTEXTKEY = @p1

Supongo que COLUMN FULLTEXTALL y COLUMN FULLTEXTKEY son en realidad Value e ID , pero eso es lo que SQL Server Profiler muestra. El problema es que el plan de consulta utiliza un escaneo de índice agrupado en aproximadamente 11M filas / 1GB de datos porque no usa el índice en la vista. Intenté crear una guía de plan para esa consulta, pero como no es una consulta T-SQL estándar, no lo permite ( Sintaxis incorrecta cerca de la palabra clave 'FULLTEXTKEY' ).

¿Hay alguna manera de hacer que este índice de texto completo funcione de otra manera que no sea:

• actualizar a SQL 2008 (o SQL 2005 Enterprise) donde funciona bien.
• creando una ID única y un índice de cobertura en la tabla subyacente.

La actualización requeriría tiempo de inactividad en el servidor y probablemente nuevas licencias de SQL Server al crear la ID única y un índice de cobertura desperdiciaría mucho espacio porque solo un subconjunto de las filas de 11M necesita indexación de texto completo ( LRVS_VALUE a menudo es NULL o tiene un valor de texto muy corto).

Answer 1

No conozco tus datos; ¿por qué no puede poner el índice de texto completo en la tabla original? Podría agregar la columna calculada en la estructura de su tabla. De esa manera no tendrías la operación de reconstrucción de índice (creo que esa es la causa de tu escaneo)

Si no puede hacerlo, es probable que el próximo cambio más fácil cree una tabla de búsqueda poblada con un sp o un activador de esa manera puede cambiar la indexación de la tabla para que tengan sentido para su consulta.

Su opción final (y una en la que necesitaría dedicar algún tiempo para acertar) sería usar tablas particionadas. Podría tener una partición que cubra los datos filtrados en la vista. Índice de texto completo de toda la tabla; su consulta en tiempo de ejecución afectaría la tabla particionada con los datos relevantes en ella.