¿Dividir ese archivo en fragmentos más pequeños (digamos 4G) sería mejor o peor para el rendimiento?
nachito
Respuestas:
13
Cuando esto puede ser un problema
Si se ejecuta show table statusen una tabla y el Data_freecampo constituye la gran mayoría del ibdata1tamaño de su archivo, es posible que tenga mucho espacio desperdiciado. Una gran cantidad de inserción / eliminación hará que eso sea un problema. Si ese es el caso y las inserciones y eliminaciones transitorias constituyen la mayor parte de sus datos, entonces tiene un buen caso para el archivo por tabla.
Sin embargo, ese no es un "sí" automático. Se habla mucho en el mundo sobre la fragmentación interna dentro de los archivos de InnoDB, pero ponerlos en un sistema de archivos como archivo por tabla simplemente mueve su fragmentación al nivel del sistema de archivos en lugar del nivel de la base de datos.
Por qué esto generalmente no es un problema
Piense en su archivo InnoDB como un sistema de archivos en lugar de un archivo. Si tiene muchos archivos, necesitará un gran sistema de archivos.
En su mayor parte, los sistemas de archivos funcionan muy bien para escalar y manejar terabytes de datos y un sinnúmero de archivos. A veces se topan con problemas con una indexación deficiente (por ejemplo, límites en la cantidad de archivos en un directorio antes de un impacto en el rendimiento), pero en su mayor parte el sistema de archivos moderno puede alcanzar el rango de terabytes.
InnoDB funciona de la misma manera. El tamaño de su archivo de datos puede ser enorme ... y, al igual que los grandes sistemas de archivos, puede presentar problemas con la copia de seguridad de sus datos. Sin embargo, al igual que dividir su sistema de archivos en múltiples particiones no ayuda con este problema, tampoco lo hace tratar de manipular innodb. Si bien puedes usar innodb_file_per_table , rara vez lo recomiendo.
Al igual que su sistema de archivos, la mejor respuesta es conocer los límites internamente y trabajar dentro de eso. Comprender los índices y aplicarlos adecuadamente. No intentes dividir InnoDB, no está hecho para eso.
Recuerdo una diapositiva de marketing de MySQL muy antigua en la que el cliente estaba ejecutando un almacén de datos con algunos terabytes. Hace muchos años. InnoDB o MyISAM, ambos funcionarían. Esto es estándar en el rack de cosas de MySQL.
Parece que estoy por debajo del 50% utilizado. InnoDB free: 7364608 kB
nachito
@nachito Parece que debería estar bien. Si cree que necesita recuperar el espacio para el sistema de archivos, reclámelo. Si solo te preocupa el rendimiento, no lo hagas. Además, para el rendimiento, lo mejor es mantener los archivos de la base de datos en su propia partición, de modo que si se concentra en el rendimiento, no vería una reclamación utilizable de todos modos.
Jeff Ferland
6
los archivos ibdata no se reducen; si recientemente eliminó algunas tablas o eliminó muchas filas, innodb en su configuración no liberará el espacio libre de nuevo al sistema de archivos. te sugeriría:
copia de seguridad de todos sus datos, por ejemplo, con mysqldump
agregar a my.cnf directiva innodb_file_per_table
reiniciar mysql
descartar todas las bases de datos usando el motor innodb
deja de mysql
eliminar el archivo ibdata
rm ib_logfile [01]
inicie mysql, verifique syslog si todo está bien
recarga tu basurero
de esta forma, podrá recuperar el espacio cada vez que suelte una tabla / base de datos innodb; los archivos idb asociados se eliminarán de inmediato.
Entiendo que nunca se reducirá sin descargar y volver a cargar las tablas. Sin embargo, si eliminé las bases de datos de InnoDB, ¿utilizará ese espacio "libre" antes de que comience a crecer nuevamente?
Su respuesta es solo una sugerencia directa sin nublar el problema como parece haber hecho mi respuesta. +1 !!!
RolandoMySQLDBA
1
Bueno, la respuesta es una solución para reducir el espacio utilizado por los archivos de datos, pero no es una discusión sobre el mérito relacionado con eso, y esa es la pregunta mientras la leo. ¿Es un archivo ibdata de 15 GB un gran problema?
Respuestas:
Cuando esto puede ser un problema
Si se ejecuta
show table statusen una tabla y elData_freecampo constituye la gran mayoría delibdata1tamaño de su archivo, es posible que tenga mucho espacio desperdiciado. Una gran cantidad de inserción / eliminación hará que eso sea un problema. Si ese es el caso y las inserciones y eliminaciones transitorias constituyen la mayor parte de sus datos, entonces tiene un buen caso para el archivo por tabla.Sin embargo, ese no es un "sí" automático. Se habla mucho en el mundo sobre la fragmentación interna dentro de los archivos de InnoDB, pero ponerlos en un sistema de archivos como archivo por tabla simplemente mueve su fragmentación al nivel del sistema de archivos en lugar del nivel de la base de datos.
Por qué esto generalmente no es un problema
Piense en su archivo InnoDB como un sistema de archivos en lugar de un archivo. Si tiene muchos archivos, necesitará un gran sistema de archivos.
En su mayor parte, los sistemas de archivos funcionan muy bien para escalar y manejar terabytes de datos y un sinnúmero de archivos. A veces se topan con problemas con una indexación deficiente (por ejemplo, límites en la cantidad de archivos en un directorio antes de un impacto en el rendimiento), pero en su mayor parte el sistema de archivos moderno puede alcanzar el rango de terabytes.
InnoDB funciona de la misma manera. El tamaño de su archivo de datos puede ser enorme ... y, al igual que los grandes sistemas de archivos, puede presentar problemas con la copia de seguridad de sus datos. Sin embargo, al igual que dividir su sistema de archivos en múltiples particiones no ayuda con este problema, tampoco lo hace tratar de manipular innodb. Si bien puedes usar innodb_file_per_table , rara vez lo recomiendo.
Al igual que su sistema de archivos, la mejor respuesta es conocer los límites internamente y trabajar dentro de eso. Comprender los índices y aplicarlos adecuadamente. No intentes dividir InnoDB, no está hecho para eso.
Como estoy luchando por transmitir el concepto de manera constructiva, he aquí una lectura rápida de las palabras mejor que yo: los terabytes no son grandes datos, los petabytes sí .
No se preocupe por una base de datos de 15 GB.
fuente
InnoDB free: 7364608 kBlos archivos ibdata no se reducen; si recientemente eliminó algunas tablas o eliminó muchas filas, innodb en su configuración no liberará el espacio libre de nuevo al sistema de archivos. te sugeriría:
de esta forma, podrá recuperar el espacio cada vez que suelte una tabla / base de datos innodb; los archivos idb asociados se eliminarán de inmediato.
fuente