Tenemos una aplicación en la que solo una de las tablas crecerá en millones de líneas, pero el resto será inferior a un millón. Entonces, ¿cuál es el consejo deberíamos ir con innodb_file_per_table o dejarlo como uno .ibd? Leí algunos artículos que dicen que no lo utilices, ya que necesitas más acceso al disco cuando hay uniones para realizar. Nos uniremos entre esta tabla y otras para generar informes.
Respuestas:
Debe ir con innodb_file_per_table y necesita hacer algo de limpieza con la infraestructura actual de InnoDB.
He visto a muchos clientes de alojamiento de bases de datos configurar MySQL y dejar InnoDB en su estado predeterminado. Esto hace que el espacio de tabla del sistema (mejor conocido como ibdata1) crezca enormemente.
Incluso si cambió a innodb_file_per_table, el archivo .ibd tendría que extraerse de ibdata1 e ibdata nunca se reducirá. Por ejemplo, si tiene una tabla llamada mydb.mytable que está dentro de ibdata1 que ocupa 2GB, para extraerla debe hacer lo siguiente:
PASO 01) Agregue esto a /etc/my.cnf
[mysqld]
innodb_file_per_tablePASO 02) service mysql restart
PASO 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;
Eso hará que el archivo /var/lib/mysql/mydb/mytable.ibd
Desafortunadamente, los 2 GB de espacio que ocupaba la mesa antes del cambio no se pueden reclamar. Escribí publicaciones anteriores sobre cómo y por qué limpiar la infraestructura de InnoDB:
Una vez que realice este cambio importante, no olvide aumentar innodb_open_files (por defecto 300) . De lo contrario, el acceso al disco es muy limitado.
Con respecto a las combinaciones, asegúrese de tener índices adecuados que admitan los criterios de combinación.
El uso de innodb_file_per_table en una instalación nueva hace que ibdata1 crezca muy lentamente porque todo DDL se realiza de forma externa a ibdata. Puede reducir cualquier tabla InnoDB como mencioné antes de esta manera:
ALTER TABLE mydb.mytable ENGINE=InnoDB;Cuando se trata de copias de seguridad, tenga mucho cuidado al hacer copias de archivos .ibd. ¿Por qué?
Dentro de cada archivo .ibd hay un valor especial conocido como tablespace_id. Hay una lista de valores de tablespace_id en ibdata1. Si alguna vez realiza el mantenimiento de la tabla que requiere soltar y volver a crear la tabla, tablespace_id será diferente. Hacer una copia de dicho archivo .ibd solo se puede volver a integrar en la base de datos para su uso si también realiza una copia de ibdata1. Eso pone en peligro el tablespace_id de todas las otras tablas de InnoDB. En vista de esto, es preferible que realice copias de seguridad de mysqldump porque mysqldump son copias lógicas de los datos. En otras palabras, la copia de seguridad es independiente del punto en el tiempo de ibdata1 y puede volver a cargarla sin problemas de operatividad.
De acuerdo con @RolandoMySQLDBA, por algo que no menciona: copias de seguridad.
Si tiene todo su régimen de copia de seguridad de MySQL funcionando, Y no está incluyendo su archivo .ibd en su estrategia de copia de seguridad del sistema de archivos, entonces esto no es tan importante. Pero considere que agregar UN BYTES a cualquier tabla innodb causará una copia de seguridad incremental de su tabla .ibd de otra manera, y puede ver que rápidamente se quedará sin almacenamiento de copia de seguridad.
Tengo una aplicación en la que tengo exactamente esta situación: algunas tablas grandes y otras más pequeñas.
Decidí dejar los pequeños en el ibdata1tiempo y poner los más grandes en sus propios archivos.
Lo hago por haber innodb_file_per_tablecambiado de forma predeterminada y sólo lo apague temporalmente para mover una mesa de ibdata1con ALTER TABLE.
ALTER TABLEellos. Entonces, mi estrategia es haber innodb_file_per_tableencendido regularmente y apagarlo casualmente para mover una mesa pequeña ibdata1y luego volver a encenderlo.