Era conveniente que MyISAM usara para almacenar cada tabla en un archivo correspondiente. InnoDB ha realizado avances en muchos aspectos, pero me pregunto por qué InnoDB almacena todas las bases de datos en un archivo ( ibdata1de forma predeterminada).

Entiendo que InnoDB asignará la ubicación de los datos en el archivo por archivos de índice individuales para tablas, pero no entiendo por qué combina todos los datos en un archivo. Y lo más importante, ¿por qué mezclar los datos de todas las bases de datos en el servidor?

Una característica interesante de MyISAM es que se puede copiar / pegar una carpeta de base de datos en otra máquina y luego usar la base de datos (sin volcar).

La arquitectura de InnoDB exige el uso de cuatro tipos básicos de páginas de información

• Páginas de datos de tabla
• Páginas de índice de tabla
• Tabla MetaData
• Datos MVCC (para soportar el aislamiento de transacciones y el cumplimiento de ACID )
  • Segmentos de reversión
  • Deshacer espacio
  • Memoria intermedia de doble escritura (escritura en segundo plano para evitar la dependencia del almacenamiento en caché del sistema operativo)
  • Insert Buffer (gestión de cambios en índices secundarios no únicos)

Vea la representación pictórica de ibdata1

Por defecto, innodb_file_per_table está deshabilitado. Esto hace que los cuatro tipos de páginas de información obtengan un solo archivo llamado ibdata1. Muchas personas intentan distribuir los datos creando múltiples archivos ibdata. Esto podría conducir a la fragmentación de datos y páginas de índice.

Es por eso que a menudo recomiendo limpiar la infraestructura de InnoDB, usando el archivo ibdata1 predeterminado y nada más .

Copiar es muy peligroso debido a la infraestructura bajo la cual trabaja InnoDB. Hay dos infraestructuras básicas.

• innodb_file_per_table deshabilitado
• innodb_file_per_table habilitado

InnoDB ( innodb_file_per_table deshabilitado)

Con innodb_file_per_table deshabilitado, todos estos tipos de información de InnoDB viven dentro de ibdata1. La única manifestación de cualquier tabla InnoDB fuera de ibdata1 es el archivo .frm de la tabla InnoDB. Copiar todos los datos de InnoDB a la vez requiere copiar todos / var / lib / mysql.

Copiar una tabla InnoDB individual es totalmente imposible. Debe volcar MySQL para extraer un volcado de la tabla como una representación lógica de los datos y sus definiciones de índice correspondientes. Luego cargaría ese volcado en otra base de datos en el mismo servidor u otro servidor.

InnoDB ( innodb_file_per_table habilitado)

Con innodb_file_per_table habilitado, los datos de la tabla y sus índices viven en la carpeta de la base de datos al lado del archivo .frm. Por ejemplo, para la tabla db1.mytable, la manifestación de esa tabla InnoDB fuera de ibdata1 sería:

• /var/lib/mysql/db1/mytable.frm
• /var/lib/mysql/db1/mytable.ibd

Sistema de tablas ibdata1

Todos los metadatos para db1.mytable todavía residen en ibdata1 y no hay absolutamente nada de eso . Los registros de rehacer y los datos de MVCC también viven con ibdata1.

Cuando se trata de la fragmentación de la tabla, esto es lo que le sucede a ibdata1:

• innodb_file_per_table habilitado : puede reducir db1.mytables conALTER TABLE db1.mytable ENGINE=InnoDB;oOPTIMIZE TABLE db1.mytable;. Esto hace que /var/lib/mysql/db1/mytable.ibd sea físicamente más pequeño sin fragmentación.
• innodb_file_per_table deshabilitado : no puede reducir db1.mytables conALTER TABLE db1.mytable ENGINE=InnoDB;oOPTIMIZE TABLE db1.mytable;porque reside con ibdata1. Al ejecutar cualquiera de los comandos, haga que la tabla sea contigua y más rápida para leer y escribir. Desafortunadamente, eso ocurre al final de ibdata1. Esto hace que ibdata1 crezca rápidamente. Esto se aborda completamente en mi publicación de limpieza de InnoDB .

ADVERTENCIA (o PELIGRO como diría el Robot en Lost in Space )

Si está pensando en copiar el archivo .frm y .ibd, está en línea para el mundo de los daños. Copiar el archivo .frm y .ibd de una tabla InnoDB solo es bueno si y solo si puede garantizar que el id del espacio de tabla del archivo .ibd coincida exactamente con la entrada de id del espacio de tabla en los metadatos del archivo ibdata1 .

Escribí dos publicaciones en DBA StackExchange sobre este concepto de id de espacio de tabla

• Tabla de compresión en InnoDB? (bajo el encabezado 'Restaurar bases de datos')
• Cómo recuperar una tabla InnoDB cuyos archivos se movieron

Aquí hay un excelente enlace sobre cómo volver a conectar cualquier archivo .ibd a ibdata1 en caso de id. De espacio de tabla no coincidentes: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Después de leer esto, debe darse cuenta de inmediato de que copiar archivos .ibd es simplemente una locura.

Para InnoDB, solo necesita algo para moverse

CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;

hacer una copia de una tabla InnoDB.

Si lo está migrando a otro servidor de base de datos, use mysqldump.

Con respecto a mezclar todas las tablas de InnoDB de todas las bases de datos, puedo ver la sabiduría al hacerlo. En la empresa de alojamiento web / DB de mi empleador, tengo un cliente MySQL que tiene una tabla en una base de datos cuyas restricciones se asignan a otra tabla en otra base de datos dentro de la misma instancia de MySQL. Con un repositorio de metadatos común, hace posible el soporte transaccional y la operatividad MVCC en múltiples bases de datos.

Puede alternar InnoDB para almacenar tablas por archivo agregando innodb-file-per-table a su cnf.

Innodb realmente se preocupa por las páginas de datos en un nivel básico. De hecho, puede configurar InnoDB para usar solo un dispositivo de bloque sin formato sin ningún sistema de archivos. http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html

Hay conveniencias para almacenar tablas para archivos, como poder recuperar más fácilmente el espacio utilizado a través de optimizar.

Incluso con archivos por tabla, no puede copiar los archivos ibd tan fácilmente, ya que InnoDB es transaccional y almacena información sobre su estado en los archivos ibdata / log compartidos globalmente.

Eso no quiere decir que no se puede hacer. Si la tabla está fuera de línea, puede descartar / importar los espacios de tabla y copiar los .idbs en http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

Este es el comportamiento predeterminado pero no obligatorio. Desde documentos de MySQL, usando espacios de tabla por tabla :

Por defecto, todas las tablas e índices de InnoDB se almacenan en el espacio de tabla del sistema. Como alternativa, puede almacenar cada tabla InnoDB y sus índices en su propio archivo . Esta característica se denomina “espacios de tabla múltiples” porque cada tabla que se crea cuando esta configuración está vigente tiene su propio espacio de tabla.

En cuanto a por qué, la razón es probablemente las diferentes arquitecturas de los dos motores (MyISAM e InnoDB). Por ejemplo, en InnoDB, no puede simplemente copiar el archivo .ibd a otra base de datos o instalación. Explicación (de la misma página):

Consideraciones de portabilidad para archivos .ibd

No puede mover libremente archivos .ibd entre los directorios de la base de datos como puede hacerlo con los archivos de tabla MyISAM. La definición de tabla almacenada en el espacio de tabla compartido InnoDB incluye el nombre de la base de datos. Los ID de transacción y los números de secuencia de registro almacenados en los archivos de espacio de tabla también difieren entre las bases de datos.