Una tabla no puede contener más de 1000 columnas.
La longitud máxima interna de una clave es 3500 bytes, pero MySQL la restringe a 1024 bytes.
La longitud máxima de fila, excepto para columnas
VARCHAR
, BLOB
y
TEXT
, es ligeramente inferior a la mitad de
una página de base de datos. Es decir, cerca de 8000 bytes.
Las columnas LONGBLOB
y
LONGTEXT
deben ser de menos de 4GB, y la
longitud total de la fila, incluyendo las columnas
BLOB
y TEXT
, debe ser de
menos de 4GB. InnoDB
almacena los primeros
768 bytes de una columna VARCHAR
,
BLOB
, o TEXT
en la fila,
y el resto, en páginas separadas.
En algunos sistemas operativos antiguos, los ficheros de datos deben ser de menos de 2GB.
El tamaño combinado de los ficheros de log de
InnoDB
debe ser inferior a 4GB.
El tamaño mínimo del espacio de tablas es de 10MB. El tamaño máximo es de cuatrocientos mil millones de páginas de base de datos (64TB). Este es también el tamaño máximo para una tabla.
Las tablas InnoDB
no admiten índices
FULLTEXT
.
Las tablas InnoDB
no admiten tipos de
columna espaciales.
ANALYZE TABLE
determina la
cardinalidad
efectuando 10 accesos al azar
en cada uno de los árboles de índices y actualizando la
cardinalidad del índice con una estimación acorde. Dado que
son solamente estimaciones, distintas ejecuciones de
ANALYZE TABLE
pueden producir resultados
diferentes. Esto convierte a ANALYZE TABLE
en una herramienta rápida sobre tablas
InnoDB
, pero no con el mismo nivel de
exactitud que si considerara todas las filas al hacer el
recuento.
MySQL emplea las estimaciones de cardinalidad de los índices
solamente para la optimización de uniones. Si una unión no
se optimiza en la manera adecuada, se puede intentar el uso de
ANALYZE TABLE
. En los pocos casso en que
ANALYZE TABLE
no produce valores
suficientemente buenos para las tablas, se puede emplear
FORCE INDEX
en las consultas para forzar el
uso de un índice en particular, o establecer el valor de
max_seeks_for_key
para asegurarse de que
MySQL dará preferencia a las búsquedas en índices por sobre
el examen de las tablas. Consulte
Sección 5.3.3, “Variables de sistema del servidor”. Consulte
Sección A.6, “Cuestiones relacionadas con el optimizador”.
En Windows, InnoDB
siempre almacena
internamente en minúsculas los nombres de tablas y bases de
datos. Para mover bases de datos en formato binario desde Unix
a Windows o a la inversa, se deberán haber escrito en
minúsculas todos los nombres de tablas y bases de datos.
Advertencia:
¡No deben convertirse las tablas de
sistema de MySQL de la base de datos mysql
desde su formato original MyISAM
a
InnoDB
! Esta es una operación no admitida.
Si se lleva a cabo, MySQL no se podrá ejecutar hasta que se
recuperen las tablas de sistema anteriores desde una copia de
respaldo o se las regenere con el script
mysql_install_db.
InnoDB
no lleva una cuenta interna de las
filas en una tabla. (Esto sería realmente complicado a causa
de la multiversión). Para procesar una sentencia
SELECT COUNT(*) FROM T
,
InnoDB
debe examinar un índice de la
tabla, lo cual lleva algún tiempo si el índice no está
completamente dentro del pool de buffer. Para disponer de un
recuento más rápido, se debe crear una tabla de recuento y
hacer que la aplicación la actualice a medida que se producen
inserciones y eliminaciones. Si una tabla no se modifica a
menudo, utilizar el cache de consultas (query cache) de MySQL
es una buena solución. También puede emplearse SHOW
TABLE STATUS
si es suficiente un recuento aproximado
de filas. Consulte Sección 15.11, “Consejos de afinamiento del rendimiento de InnoDB
”.
Para una columna AUTO_INCREMENT
, siempre se
debe definir un índice para la tabla, el cual debe contener
solamente a la columna AUTO_INCREMENT
. En
tablas MyISAM
, la columna
AUTO_INCREMENT
puede formar parte de un
índice junto a otras columnas.
InnoDB
no admite la opción
AUTO_INCREMENT
en sentencias
CREATE TABLE
o ALTER
TABLE
, la cual sirve para establecer el valor
inicial de la secuencia. Para especificar este valor en
InnoDB
, debe insertarse una fila con un
valor que sea uno menos que el deseado, y luego borrarla, o
insertar la primera fila especificando un valor determinado.
Luego de reiniciar el servidor MySQL,
InnoDB
puede reutilizar un valor antiguo
para una columna AUTO_INCREMENT
(esto es,
un valor que se hubiese asignado a una transacción finalmente
cancelada).
Cuando una columna AUTO_INCREMENT
sobrepasa
el máximo valor que es capaz de almacenar,
InnoDB
coloca la columna en
-9223372036854775808
(si es
BIGINT
) o en 1
(si es
BIGINT UNSIGNED
). Sin embargo, como los
valores BIGINT
tienen 64 bits, hay que
notar que si se insertara un millón de filas por segundo, se
demoraría cerca de trescientos mil años en agotar los
números disponibles. Con otros tipos de columnas enteros,
ocurre un error de clave duplicada. Esto es similar al
funcionamiento de MyISAM
, ya que es en
mayor medida el comportamiento general de MySQL y no pertenece
a ningún motor de almacenamiento en particular.
DELETE FROM
no regenera la
tabla sino que elimina todas sus filas, una por una.
nom_tabla
TRUNCATE
se implementa en
tbl_name
InnoDB
como DELETE FROM
y no inicializa
el contador de tbl_name
AUTO_INCREMENT
.
SHOW TABLE STATUS
no proporciona
estadísticas precisas en tablas InnoDB
,
excepto para el tamaño físico reservado por la tabla. El
recuento de filas es solamente una estimación utilizada para
la optimización SQL.
En MySQL 5.0, la operación LOCK TABLES
establece dos bloqueos en cada tabla si
innodb_table_locks=1
, que es el valor por
defecto. Adicionalmente al bloqueo de tabla en la capa MySQL,
también se establece un bloqueo de tabla en
InnoDB
. En versiones antiguas de MySQL no
se establecía el bloqueo en InnoDB
, para
volver a este comportamiento debe especificarse
innodb_table_locks=0
. Si no se establece el
bloqueo InnoDB
, LOCK
TABLES
se completa aún cuando algunos registros de
las tablas estén bloqueados por otras transacciones.
Todos los bloqueos InnoDB
efectuados por
una transacción se liberan cuando la transacción se confirma
o se cancela. Por lo tanto, no tiene mucho sentido invocar
LOCK TABLES
en tablas
InnoDB
cuando se está en el
modoAUTOCOMMIT=1
, porque los bloqueos
establecidos sobre una tabla InnoDB
se
liberarán inmediatamente.
Algunas veces sería útil bloquear tablas extensas en el
curso de una trasacción. Desafortunadamente, LOCK
TABLES
, en MySQL, emite implícitamente un
COMMIT
y un UNLOCK
TABLES
. Está planeada una variante para InnoDB de
LOCK TABLES
que puede ejecutarse dentro de
una transacción.
La sentencia LOAD TABLE FROM MASTER
empleada para la replicación de servidores esclavos no
funciona aún con tablas InnoDB
. Una
solución temporal es cambiar a MyISAM
la
tabla en el servidor amo (master), efectuar la carga, y volver
a cambiar la tabla en el amo (master) a su motor original
InnoDB
.
El tamaño por defecto de cada página de base de datos en
InnoDB
es de 16KB. Se puede establecer en
valores entre 8KB y 64KB recompilando el código. Se deben
modificar los valores de UNIV_PAGE_SIZE
y
UNIV_PAGE_SIZE_SHIFT
en el fichero fuente
univ.i
.
En MySQL 5.0, los disparadores (triggers) aún no son activados por modificaciones efectuadas en cascada a través de claves foráneas.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.