¿Por qué usar innodb_file_per_table?
Porque es más fácil de administrar individualmente, ya que se puede hacer a nivel de archivo. Esto significa que incluso si el servidor está caído, aún puede copiar datos copiando los archivos de la tabla, mientras que usar un espacio de tabla compartido significa copiar todo lo que puede ser innecesariamente masivo o encontrar alguna forma de hacer que el servidor se ejecute para extraer datos ( realmente no desea extraer manualmente los datos con un editor hexadecimal).
Alguien advirtió que no puede simplemente copiar y pegar .ibdarchivos de un servidor a otro. Esto puede ser cierto, pero no debería aplicarse a las copias de seguridad en el mismo servidor (estoy usando el término copia de seguridad aquí en el sentido tradicional de hacer una copia; es decir, no cambiar drásticamente todo el asunto). Además, ibdata1se vuelve a crear automáticamente al inicio (como se ve en el paso de eliminaciónibdata1 de la mayoría de las guías de "conversión a archivo por tabla"). Como tal, no necesita copiar ibdata1además de sus .ibdarchivos (y sus .frmarchivos correspondientes , etc.).
Si intenta recuperar una tabla perdida, debería ser suficiente copiarla .ibdy su .frmarchivo, así como information_schema(que es mucho más pequeño que ibdata1). De esa manera, puede ponerlos en un servidor ficticio y extraer su tabla sin tener que copiar todo el conjunto.
Sin embargo, la afirmación de un mejor rendimiento es cuestionable. ... Con innodb_file_per_table, se necesitan más operaciones de E / S de disco; y esto es significativo en las restricciones complicadas de JOIN y FOREIGN KEY.
No es sorprendente que el rendimiento dependa completamente de las bases de datos específicas en uso. Una persona tendrá (incluso mucho) diferentes resultados de otra.
Es cierto que habrá más operaciones de E / S de disco con archivo por tabla, pero solo un poco más. Piensa en cómo funciona el sistema.
Notará que cuando el servidor se está ejecutando, no puede mover los archivos de datos porque el servidor tiene identificadores abiertos para ellos. Esto se debe a que cuando se inicia, los abre y los deja abiertos. No los abre ni los cierra para cada consulta individual.
Como tal, solo hay algunas operaciones de E / S más al principio, cuando se inicia el servidor; No mientras se está ejecutando. Además, aunque cada .ibdarchivo individual tiene su propia sobrecarga separada (firmas de archivo, estructuras, etc.), se almacenan en la memoria caché y no se vuelven a leer para cada consulta. Además, las mismas estructuras se leen incluso con un espacio de tabla compartido, por lo que apenas se necesita (si es que hay alguna) más memoria.
¿Innodb_file_per_table tiene un efecto en un mejor rendimiento de mysql?
En realidad, en todo caso, el rendimiento puede ser peor .
Cuando se utiliza un espacio de tabla compartido, las operaciones de lectura y escritura a veces / a menudo se pueden combinar para que el servidor lea una muestra de datos de varias tablas de una sola vez. ibdata .
Sin embargo, si los datos se distribuyen entre varios archivos, entonces debe realizar una operación de E / S por separado para cada uno.
Por supuesto, esto depende nuevamente de la base de datos en cuestión; El impacto en el rendimiento del mundo real dependerá del tamaño, la frecuencia de las consultas y la fragmentación interna del espacio de tabla compartido. Algunas personas pueden notar una gran diferencia, mientras que otras pueden no ver ningún impacto en absoluto.
Tablespace se comparte en ibdata individual; ¿Cómo los espacios de tabla dedicados para tablas separadas pueden ahorrar espacio en disco?
No es asi. En todo caso, aumenta un poco el uso del disco.
No tengo una base de datos de 60 GB para probar, pero mi base de datos personal "miserable" que contiene mi instalación de WordPress y algunas tablas pequeñas para uso personal y pruebas de desarrollo pesaron ~ 30 MB mientras usaba un espacio de tabla compartido. Después de convertirlo a archivo por tabla, se hinchó a ~ 85 MB. Incluso al soltar todo y volver a importar, todavía era> 60 MB.
Este aumento se debe a dos factores:
El tamaño mínimo absoluto para ibdata1es, por alguna razón, 10 MB, incluso si no tiene nada más que information_schemaalmacenado en él.
Con un espacio de tabla compartido, solo ibdata1tiene gastos generales como firmas de archivo, metadatos, etc., pero con cada tabla, cada .ibdarchivo individual tiene todo eso. Esto significa que el total (incluso con un hipotético <10 MB ibdata1) sería algo mayor al menos:
GetTotalSizeofOverhead() * GetNumTables()
Obviamente, estos no van a ser grandes aumentos (a menos que esté utilizando un host que limite el tamaño de su base de datos o los almacene en una unidad flash, etc.), pero de todos modos son aumentos, y al cambiar ( cada ) tabla a archivo -por tabla puede reducirse ibdata1a 10 MB, el total general invariablemente será más de lo que era.