vista optimizar optimizacion indexada consultas sql mysql views materialized-views indexed-view

optimizacion - optimizar consultas mysql explain



¿Es posible tener una vista indexada en MySQL? (4)

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

La idea básica es que tenga una versión de los datos que se modifica regularmente, esta sería la parte de procesamiento de transacciones y requiere una gran normalización 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 ser 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 cubos de almacenamiento de datos, y están compuestos por tablas de hechos que representan los lados del cubo y las tablas de dimensiones que representan los bordes del cubo.

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 muchas cosas pueden cambiar en 3-4 años.

Lo que estoy buscando es una forma de tener un índice sobre una vista pero hacer que la tabla que se ve permanezca sin indexar. La indexación perjudica 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 índice hace que mis consultas sean muy lentas.


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

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

Si esta es una tabla de solo escritura (es decir, no necesita hacer actualizaciones), puede ser mortal en MySQL para comenzar a archivarla, o borrar registros (y claves de índice), lo que requiere que el índice comience a llenarse (reutilizar) ranuras de claves eliminadas, en lugar de simplemente agregar nuevos valores de índice. Contra-intuitivo, pero es mejor que tengas una mesa más grande en este caso.


No creo que MySQL soporte vistas materializadas, que es lo que necesitarías, pero de todos modos no te ayudaría en esta situación. Si el índice está en la vista o en la tabla subyacente, debería 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 opción sería crear tablas de resumen que se actualicen periódicamente.


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 SQL soportado por la vista es un poco restringido (como las rutinas de registro de cambios tienen que descubrir qué tablas debe rastrear para los cambios), pero hasta donde yo sé, esto es lo más cercano que se puede obtener a vistas materializadas en MySQL .