Vista Indexada vs Índices en Tabla
Tengo 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 estado creando un informe, y encontramos que el rendimiento apesta. 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, hay una preocupación por el rendimiento del contador de pesaje. Para los informes, me inclino a poner índices en cada columna porque las columnas de origen y descripción deben buscarse subcadenas.
Nos preguntamos si un indexed view (también conocida como materialized view) sería una opción, donde la vista indexada contendría todas las columnas de la tabla EVENT_LOG pero tendría los índices apropiados creados en la vista. ¿Esto nos daría el rendimiento para la presentación de informes, sin afectar las escrituras en la tabla EVENT_LOG?
5 answers
Una vista indexada causará los mismos problemas que un índice en la columna, porque las vistas indexadas requieren with schemabinding, que la vinculan directamente a la tabla, lo que le impide cambiar/alterar el esquema de esa tabla de cualquier manera, forma o forma. Esto incluye cambiar el tamaño de una columna (por ejemplo-de varchar(50) a varchar(255)), cambiar 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 SSIS paquete que creará una tabla de informes para usted que se ejecuta cada hora más o menos. De esta manera, puede indexar el infierno siempre amoroso y disfrutar de todos los beneficios de rendimiento que produce. Me da vergüenza informar de un sistema en vivo y en progreso. En realidad aún no he visto el caso donde esto es necesario. Para fines de informes, la información de una hora de antigüedad suele ser absolutamente suficiente para hacer el trabajo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-08-27 19:41:31
Creo que todavía afectaría el rendimiento, ya que los índices en la vista materializada deben actualizarse en algún momento, aunque probablemente no tenga que ser sincrónico con las escrituras de la tabla.
Personalmente pondría los índices sobre la mesa y mediría el rendimiento de escritura yo mismo. Puedes adivinar cuánto más lentas serían las escrituras con los índices ahí, pero hasta que realmente lo midas solo estás especulando. Podría no hacer una diferencia notable en todo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-08-27 19:41:12
" Se deben buscar subcadenas en las columnas fuente y descripción. "
Cuando busca subcadenas en las columnas varchar (), SQL Server no va a usar ningún índice.(incluso si replica la tabla y crea índices) Los índices no se utilizan si se utiliza un carácter comodín al inicio de la cadena de búsqueda .
Supongo que es mejor crear un Índice de Texto Completo en 'Fuente' y 'Descripción', si necesita buscar subcadenas en ellos.
Así que mi sugerencia sería crear un Índice de Texto Completo en las columnas varchar() y hacer el Seguimiento de Cambios como Manual y ejecutarlo cada hora más o menos cuando no hay DML ... lo que disminuiría las cargas en las instrucciones INSERT
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-15 17:39:28
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 a menudo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-08-27 19:42:11
Me encontré con un problema similar. Decidió agregar el índice de varias columnas contra el asesoramiento de DBA. En mi máquina de desarrollo y el servidor (con permiso DBA), el rendimiento para escribir aumentó y los informes fueron significativamente más rápidos (17 veces) que crear índices en columnas individuales. Por qué, no lo sé ya que no soy un DBA, pero sí sé lo básico, y a veces eso te ayuda a ver a través del bosque/árboles. Por lo tanto, estoy de acuerdo con Eric Pertroelje, debe agregar índices y medir la escritura rendimiento e incluso medir el rendimiento de lectura.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-30 01:16:05