Por defecto, MySQL InnoDB almacena todas las tablas de todos los DB en un archivo global. Puede cambiar esto configurando innodb_file_per_table en la configuración, que luego crea un archivo de datos para cada tabla.

Me pregunto por qué innodb_file_per_tableno está habilitado de forma predeterminada. ¿Hay inconvenientes para usarlo?

Tengo la respuesta completa para esta.

Una vez que innodb_file_per_table se establece, y las nuevas tablas de InnoDB se pueden ALTER TABLE <innodb-table-name> ENGINE=InnoDB';reducir utilizando Esto reducirá los .ibdarchivos nuevos GARANTIZADOS.

Si ejecuta ALTER TABLE <innodb-table-name> ENGINE=InnoDB';una tabla InnoDB creada antes de usar innodb_file_per_table, extraerá los datos e índices de esa tabla del archivo ibdata1 y la almacenará en un .ibdarchivo. Esto dejará una paloma permanente entera en ibdata1 que nunca podrá reutilizarse. .

El ibdata1archivo normalmente alberga cuatro tipos de información.

• Datos de tabla
• Índices de tabla
• Datos MVCC (Control de concurrencia multiversionante)
  • Segmentos de reversión
  • Deshacer espacio
• Metadatos de tabla (Diccionario de datos)
• 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)
• Ver el Pictorial Representation of ibdata1

Aquí está la forma garantizada de reducir el archivo ibdata1 casi para siempre ...

PASO 01) MySQL Vuelca todas las bases de datos en un archivo de texto SQL (llámalo SQLData.sql)

PASO 02) Descarte todas las bases de datos (excepto los esquemas mysql, information_schema y performance_schema)

PASO 03) Apague mysql

PASO 04) Agregue las siguientes líneas a /etc/my.cnf

[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend

Nota al margen: cualquiera que sea su conjunto para innodb_buffer_pool_size, asegúrese de que innodb_log_file_size sea el 25% de innodb_buffer_pool_size.

• PASO 05) Elimine ibdata1, ib_logfile0 e ib_logfile1 ( consulte la actualización a continuación antes de eliminar )

En este punto, solo debe haber el esquema mysql en / var / lib / mysql

• PASO 06) Reinicie mysql

Esto recreará ibdata1 a 10MB (no configure la opción), ib_logfile0 e ib_logfile1 a 1G cada uno

• PASO 07) Vuelva a cargar SQLData.sql en mysql

ibdata1 crecerá pero solo contendrá metadatos de tabla y datos MVCC intermitentes.

Cada tabla InnoDB existirá fuera de ibdata1

Supongamos que tiene una tabla InnoDB llamada mydb.mytable. Si ingresa /var/lib/mysql/mydb, verá dos archivos que representan la tabla

• mytable.frm (Encabezado del motor de almacenamiento)
• mytable.ibd(Inicio de datos de tabla e índices de tabla para mydb.mytable)

ibdata1 nunca contendrá más datos e índices de InnoDB.

Con la opción innodb_file_per_table/etc/my.cnf , puede ejecutar OPTIMIZE TABLE mydb.mytableOR ALTER TABLE mydb.mytable ENGINE=InnoDB;y el archivo /var/lib/mysql/mydb/mytable.ibdse reducirá.

Lo he hecho varias veces en mi carrera como DBA MySQL sin tener ni un solo problema a partir de entonces. De hecho, la primera vez que hice esto, colapsé un archivo ibdata1 de 50 GB en 50 MB.

Darle una oportunidad. Si tiene más preguntas sobre esto, envíeme un correo electrónico. Créeme. Esto funcionará a corto plazo y a largo plazo.

ACTUALIZACIÓN 2013-07-02 15:08 EDT

Hay una advertencia que tengo al respecto que actualicé en otras publicaciones mías, pero me perdí esto: estoy actualizando mi respuesta un poco más con innodb_fast_shutdown porque solía reiniciar mysql y detener mysql para hacer esto. Ahora, este paso es vital porque cada transacción no comprometida puede tener otras partes móviles dentro y fuera de los InnoDB Transaction Logs ( Ver Infraestructura InnoDB ).

Tenga en cuenta que establecer innodb_fast_shutdown en 2 también eliminaría los registros, pero aún existen más partes móviles y se selecciona en Crash Recovery durante el inicio de mysqld. La configuración de 0 es la mejor.

Ver insecto .

¿Hay inconvenientes para usarlo?

• más archivos abiertos
• abrir / reabrir sobrecarga
• El archivo .ibd no se contrae (ver 1 , 2 )

Siempre uso innodb_file_per_table en grandes bases de datos.

innodb_file_per_table está habilitado por defecto en MariaDB.

La razón por la que opté por no usar innodb_file_per_table, es porque cada tabla se coloca en su propio archivo, lo que significa que cada tabla tiene su propia sobrecarga separada (firmas de archivo, etc.) que hace que el tamaño total del MySQLdirectorio sea total. más grande que si usa un espacio de tabla compartido. Además, hay más espacio desperdiciado debido a la holgura del clúster cuando se tienen múltiples archivos pequeños en lugar de uno solo y grande.

De acuerdo, la sobrecarga adicional no es una cantidad masiva en el gran esquema de las cosas, especialmente si está utilizando una unidad de disco grande o tiene una base de datos gigante, pero para mí (y probablemente para muchos "usuarios domésticos"), todo se suma y Todavía era demasiado para el pequeño disco con grandes grupos donde guardaba mi tienda MySQL.

Por ejemplo, mi tienda de bases de datos con mis bases de datos de WordPress y algunas otras bases de datos pequeñas (phpBB, dev, algunas pruebas de AMP, etc.), la conversión a por tabla lo cambió de 32 MB a 50 MB, y eso ni siquiera incluye el ibdata1que todavía requiere un mínimo de 10 MB , para un total de al menos 60 MB .

Como dije, esto puede no ser un gran problema para algunas personas, especialmente para las empresas, pero si usted es un usuario doméstico que solo aloja su sitio, blog, etc., entonces puede ser un factor en cosas como elegir un proveedor de host porque muchos hosts limitan el tamaño de su base de datos además del uso total del disco.

Solo para agregar un poco más de información

Desde mysql 5.6.6 está habilitado por defecto

con innodb_file_per_table = 1, la tabla desplegable puede ser más lenta, vea aquí