mysql - motores - Unir tablas InnoDB con tablas MyISAM
myisam o innodb (2)
Lo que salta inmediatamente a mí es MyISAM .
ASPECTO # 1: El JOIN mismo
Siempre que haya uniones que involucren MyISAM e InnoDB, las tablas InnoDB terminarán teniendo un comportamiento de bloqueo de nivel de tabla en lugar de un bloqueo de nivel de fila debido a la participación de MyISAM en la consulta y MVCC no se puede aplicar a los datos de MyISAM. MVCC ni siquiera se puede aplicar a InnoDB en algunos casos.
ASPECTO # 2: Participación de MyISAM
Desde otra perspectiva, si alguna tabla MyISAM se actualiza a través de INSERT, UPDATE o DELETE, las tablas MyISAM involucradas en una consulta JOIN se bloquearán desde otras conexiones DB y la consulta JOIN tendrá que esperar hasta que se puedan leer las tablas MyISAM. Desafortunadamente, si hay una mezcla de InnoDB y MyISAM en la consulta JOIN, las tablas InnoDB tendrían que experimentar un bloqueo intermitente como sus socios MyISAM en la consulta JOIN debido a que se detuvo desde la escritura.
Tenga en cuenta que MVCC aún permitirá que las transacciones READ-UNCOMMITTED y REPEATABLE-READ funcionen bien y permita que ciertas vistas de datos estén disponibles para otras transacciones. No puedo decir lo mismo para READ-COMMITTED y SERIALIZABLE .
ASPECTO # 3: Optimizador de consultas
MySQL depende de la cardinalidad del índice para determinar un plan optimizado de EXPLAIN. La cardinalidad del índice es estable en las tablas MyISAM hasta que se producen muchas INSERT, UPDATE y DELETE en la tabla, mediante las cuales se puede ejecutar OPTIMIZE TABLE periódicamente contra las tablas MyISAM. ¡La cardinalidad del índice InnoDB NUNCA ES ESTABLE! Si ejecuta SHOW INDEXES FROM *innodbtable*; , verás que la cardinalidad del índice cambia cada vez que ejecutas ese comando. Eso es porque InnoDB hará inmersiones en el índice para estimar la cardinalidad. Incluso si ejecuta OPTIMIZE TABLE contra una tabla InnoDB, eso solo desfragmentará la tabla. OPTIMIZE TABLE ejecutará ANALYZE TABLE internamente para generar estadísticas de índice en la tabla. Eso funciona para MyISAM. InnoDB lo ignora.
Mi consejo para usted es hacer todo lo posible y convertir todo a InnoDB y optimizar su configuración en consecuencia.
ACTUALIZACIÓN 2012-12-18 15:56 EDT
Créalo o no, todavía hay un boleto abierto en la unión de InnoDB / MyISAM durante un SELECCIONAR PARA ACTUALIZAR . Si lo lees, resume la resolución de la siguiente manera: ¡NO LO HAGAS! .
Tenemos un conjunto de tablas que contienen los datos del nivel meta como organizaciones, usuarios de la organización, departamentos de la organización, etc. Todas estas tablas se leerán abundantemente con muy pocas operaciones de escritura. Además, los tamaños de la tabla serían bastante pequeños (la cantidad máxima de registros sería de alrededor de 30 K - 40 K)
Otro conjunto de datos OLTP de la tienda de tablas, como transacciones de facturas, acciones del usuario, etc. que serán tanto de lectura como de escritura pesadas. Estas tablas serían bastante grandes (alrededor de 30 millones de registros por mesa)
Para el primer conjunto de tablas planeamos ir con MyISAM y para el segundo con el motor InnoDb. Muchas de nuestras características también requerirían UNIONES en tablas de estos 2 conjuntos.
¿Hay algún problema de rendimiento al unir tablas MyISAM con tablas InnoDB? Además, ¿hay algún otro problema posible (copias de seguridad db, ajustes, etc.) que podamos encontrar con este tipo de diseño?
Cualquier comentario sería muy apreciado.
No creo que la gestión de transacciones funcione correctamente o en absoluto, ya que las tablas MyISAM no lo manejan.