vista indizada vs Índices en la Tabla

Question

que tiene la siguiente tabla

EVENT_LOG:

EVENT_ID: pk, int, not null 
TYPEID: fk, int, not null 
CATEGORYID: fk, int, null 
SOURCE: varchar(255), null 
DESCRIPTION: varchar(4000), null 
CREATED: datetime, null 

Hemos sido la creación de un informe, y se encontró que el rendimiento chupa. No hay ningún índice aparte del agrupado. Podríamos crearlos, pero debido a que esta tabla está escrita en más de lo que se lee, existe una preocupación por el rendimiento del pesaje. Para los informes, me inclino a poner índices en cada columna porque las columnas de la fuente & deben buscarse en las subcadenas.

Nos preguntamos si una indexed view (vista materializada AKA) sería una opción, donde la vista indexada contendría todas las columnas de la tabla EVENT_LOG pero tiene los índices apropiados creados en la vista. ¿Esto nos daría el rendimiento para informar, mientras no impacta las escrituras en la tabla EVENT_LOG?

Answer 1

Una vista indizada causará los mismos problemas que un índice en la columna, porque las vistas indizadas requieren with schemabinding, que lo vinculan directamente a la tabla, impidiéndole cambiar/alterar el esquema de esa tabla de ninguna manera, forma, o forma. Esto incluye cambiar el tamaño de una columna (por ejemplo, de varchar(50) a varchar(255)), cambiando el tipo de datos de una columna (por ejemplo, de double a decimal(18,5)), etc. Los he visto causar muchos dolores de cabeza inesperados debido a este hecho.

Mi sugerencia es configurar un procedimiento almacenado o paquete SSIS que creará una tabla de informes para usted que se ejecuta cada hora más o menos. De esta forma, puedes indexar el infierno siempre amoroso y disfrutar de todos los beneficios de rendimiento que produce. Me da pena no informar desde un sistema en vivo, en progreso. De hecho, aún no he visto el caso en que esto sea necesario. Para fines de informes, la información de una hora es, por lo general, absolutamente suficiente para realizar el trabajo.

Answer 2

Creo que todavía impactaría en el rendimiento, ya que los índices de la vista materializada necesitan actualizarse en algún momento; sin embargo, probablemente no tenga que ser sincrónico con las escrituras de la tabla.

Personalmente pongo los índices sobre la mesa y mido el rendimiento de escritura. Puede adivinar cuánto escribir más lento sería con los índices allí, pero hasta que realmente lo mida, solo está especulando. Es posible que no haga una diferencia notable en absoluto.

Answer 3

No si va a escribir a menudo, ya que tendría el costo de rendimiento del índice en su vista materializada. Las Vistas materializadas son más para datos que no cambian con frecuencia.

Answer 4

Me encontré con un problema similar. Decidió agregar un índice de varias columnas contra el consejo de DBA. En mi máquina de desarrollo y el servidor (con permiso de DBA), el rendimiento para escribir aumentó y los informes fueron significativamente más rápidos (17x) que la creación de índices en columnas individuales. No sé porque no soy un DBA, pero sé lo básico, y a veces eso te ayuda a ver a través del bosque/los árboles. Por lo tanto, estoy de acuerdo con Eric Pertroelje, debe agregar índices y medir el rendimiento de escritura e incluso medir el rendimiento de lectura.

Answer 5

"La fuente & columnas de descripción tienen que ser buscados subcadenas."

cuando la búsqueda de subcadenas en la varchar() columnas, SQL Server no se va a utilizar cualquier índice.(incluso si replica la tabla y crea índices) Los índices no se utilizan, si se usa un carácter comodín al comienzo de su cadena de búsqueda.

supongo, es mejor crear un índice de texto completo en la 'Fuente' y 'Descripción', si es necesario buscar subcadenas en ellos.

Así que mi sugerencia sería crear un índice de texto completo en columnas varchar() y hacer que Change-Tracking sea Manual y ejecutarlo cada hora más o menos cuando no haya DML ... lo que disminuiría las cargas en el las instrucciones INSERT