Pregunta

Encontré una publicación en los foros de MySQL desde 2005 , pero nada más reciente que eso. Basado en eso, no es posible. Pero mucho puede cambiar en 3-4 años.

Lo que estoy buscando es una forma de tener un índice sobre una vista pero que la tabla que se ve permanezca sin indexar. La indexación daña el proceso de escritura y esta tabla se escribe con bastante frecuencia (hasta el punto en que la indexación ralentiza todo a un rastreo). Sin embargo, esta falta de un índice hace que mis consultas sean muy lentas.

¿Fue útil?

Solución

No creo que MySQL admita vistas materializadas, es lo que necesitarías, pero no te ayudaría en esta situación de todos modos. Ya sea que el índice esté en la vista o en la tabla subyacente, tendría que escribirse y actualizarse en algún momento durante una actualización de la tabla subyacente, por lo que aún causaría problemas de velocidad de escritura.

Su mejor apuesta probablemente sería crear tablas de resumen que se actualicen periódicamente.

Otros consejos

¿Ha considerado abstraer sus datos de procesamiento de transacciones de sus datos de procesamiento analítico para que ambos puedan especializarse para cumplir con sus requisitos únicos?

La idea básica es que tiene una versión de los datos que se modifica regularmente, esta sería la parte de procesamiento de transacciones y requiere una normalización pesada e índices ligeros para que las operaciones de escritura sean rápidas. Una segunda versión de los datos está estructurada para el procesamiento analítico y tiende a estar menos normalizada y más indexada para las operaciones de informes rápidos.

Los datos estructurados en torno al procesamiento analítico generalmente se basan en la metodología de almacenamiento de datos del cubo, y están compuestos por tablas de hechos que representan los lados del cubo y tablas de dimensiones que representan los bordes del cubo.

Flexviews admite vistas materializadas en MySQL mediante el seguimiento de los cambios en las tablas subyacentes y la actualización de la tabla que Funciona como una vista materializada. Este enfoque significa que el SQL soportado por la vista es un poco restringido (ya que las rutinas de registro de cambios tienen que averiguar qué tablas deben rastrear los cambios), pero por lo que sé, esto es lo más cerca que puede estar de las vistas materializadas en MySQL. .

¿Solo quieres una vista indexada? Es poco probable que escribir en una tabla con un solo índice sea tan perjudicial. ¿No hay una clave principal?

Si cada registro es grande, puede mejorar el rendimiento al descubrir cómo acortarlo. O acortar la longitud del índice que necesita.

Si esta es una tabla de solo escritura (es decir, no necesita hacer actualizaciones), en MySQL puede ser mortal comenzar a archivarla o, de lo contrario, eliminar registros (y claves de índice), lo que requiere que el índice comience a llenarse (reutilizando) las ranuras de las claves eliminadas, en lugar de simplemente agregar nuevos valores de índice. Es contrario a la intuición, pero en este caso está mejor con una mesa más grande.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top