Preguntes Freqüents - FAQ

ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

Este comando analiza y almacena la distribución de clave
para una tabla. Durante el análisis, la tabla se bloquea con
un bloqueo de lectura. En MySQL 5.0, funciona en tablas
MyISAM,
BDB, y InnoDB . Para
tablas MyISAM , este comando es
equivalente a usar myisamchk -a.


MySQL usa la distribución de claves almacenada para
decidir el orden en que las tablas deben hacer los joins
cuando realiza uno en algo que no sea una constante.

El comando retorna una tabla con las siguientes columnas:


Puede chequear la distribución de claves almacenada con
el comando SHOW INDEX .
Consulte

Sección 13.5.4.11, ?Sintaxis de SHOW
INDEX?.

Si la tabla no ha cambiado desde el último comando
ANALYZE TABLE , la tabla no se
vuelve a analizar.

En MySQL 5.0, los comandos ANALYZE
TABLE se escriben en el log binario a no ser que la
palabra clave NO_WRITE_TO_BINLOG
opcional (o su alias LOCAL) se
use.

BACKUP TABLE tbl_name [, tbl_name] ... TO '/path/to/backup/directory'

Nota: Este
comando está obsoleto. Estamos trabajano en un mejor
sustituto para este que proporcionará capacidades de copia
de seguridad en línea. De momento, el script
mysqlhotcopy puede usarse.


BACKUP TABLE copia al
directorio de base de datos el mínimo número de ficheros de
tablas necesarias para restaurar la tabla, tras volcar
cualquier cambios almacenados en el buffer a disco. El
comando funciona sólo para tablas
MyISAM . Copia los ficheros de definición
.frm y de datos
.MYD . El fichero índice
.MYI puede reconstruirse desde
estos otros. El directorio debe especificarse con la ruta
entera.

Antes de usar este comando consulte

Sección 5.8.1, ?Copias de seguridad de bases de datos?.


Durante la copia de seguridad, se realiza un bloqueo de
lectura para cada tabla, uno cada vez, mientras se hace la
copia. Si quier hacer una copia de seguridad de varias
tablas como una muestra (evitando que ninguna de ellas se
cambie durante la operación de la copia de seguridad), debe
realizar un comando LOCK TABLES
para obtener un bloqueo de lectura para cada tabla en el
grupo.

El comando retorna una tabla con las siguientes columnas:


CHECK TABLE tbl_name [, tbl_name] ... [option] ...


option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

Chequea una tabla o tablas para errores.
CHECK TABLE funciona para
tablas MyISAM y
InnoDB . Para tablas
MyISAM , la estadística de
clave se actualiza.

Desde MySQL 5.0.2, CHECK TABLE
puede comprobar las vistas en busca de problemas tales como
tablas que se referencian en la definición de la vista que
ya no existe.

El comando CHECK TABLE
retorna una tabla con las siguientes columnas:

Tenga en cuenta que el comando puede producir varios
registros para información de cada tabla chequeada. El
último registro tiene un valor
Msg_type de status y
Msg_text normalmente debe ser
OK. Si no obtiene
OK, o
Table is already up to date debe realizar una
reparación de la tabla. Consulte

Sección 5.8.3, ?Mantenimiento de tablas y recuperación de un
fallo catastrófico (crash)?. Table
is already up to date significa que el motor de
almacenamiento para la tabla indicada indica que no hay
necesidad de chequear la tabla.

Las distintas opciones de chequeo que pueden darse se
muestran en la siguiente tabla. Estas opciones se aplican
sólo para tablas MyISAM y se
ignoran en tablas InnoDB y
vistas.

Si ninguna de las opciones QUICK,
MEDIUM, o
EXTENDED se especifica, el tipo de chequeo por
defecto para tablas de formato dinámico
MyISAM es
MEDIUM. Esto es lo mismo que ejecutar
myisamchk --medium-check
tbl_name
en la tabla. El tipo de chequeo por defecto también es
MEDIUM para tablas
MyISAM de formato estático, a
no ser que se especifique CHANGED
o FAST. En tal caso, por
defecto es QUICK. El escaneo de
registro se evita para CHANGED
y FAST porque los registros
están corruptos muy raramente.

Puede combinar opciones de chequeo, como en el siguiente
ejemplo, que realiza un chequeo rápido de la tabla para ver
si se cerró correctamente:

CHECK TABLE test_table FAST QUICK;

Nota: En
algunos casos, CHECK TABLE
cambia la tabla. Esto ocurre si la tabla se marca como ?corrupted?
o ?not closed properly? pero
CHECK TABLE no encuentra ningún
problema en la tabla. En este caso,
CHECK TABLE marca la tabla como correcta.

Si una tabla está corrupta, es más probable que el
problema esté en el índice y no en la parte de datos. Todos
los tipos de chequeo chequean los índices profundamente y
deberían encontrar la mayoría de errores.

Si quiere chequear una tabla que asume como correcta, no
debe usar opciones de chequeo o la opción
QUICK. Ésta debe usarse cuando
tiene prisa y puede permitirse el pequeño riesgo que
QUICK no encuentre un error en
el fichero de datos. (En la mayoría de casos, MySQL debería
encontrar, bajo uso normal, cualquier error en el fichero de
datos. Si esto ocurre, la tabla se marca como ?corrupted?
y no puede usarse hasta que se repare.)

FAST y
CHANGED están pensados para usar desde un script (por
ejemplo, para ejecutarse desde cron)
si quiere chequear sus tablas de vez en cuando. En la
mayoría de casos, FAST se
prefiere en lugar de CHANGED.
(El único caso en que no es el método preferido es cuando
sospecha que ha encontrado un bug en el código
MyISAM .)

EXTENDED debe usarse sólo
después de ejecutar un chequeo normal pero todavía obtiene
errores extraños de la tabla cuando MySQL intenta actualizar
un registro o encuentra un registro mediante la clave. (Esto
es muy improbable si un chequeo normal ha tenido éxito.)

Algunos problemas reportados por
CHECK TABLE no pueden corregirse automáticamente:

CHECKSUM TABLE tbl_name [, tbl_name] ... [ QUICK | EXTENDED ]

Reporta un checksum de tabla.

Si QUICK se especifica, el
checksum de la tabla se reporta si está disponible, o
NULL en otro caso. Esto es muy
rápido. Un checksum en vivo está permitido especificando la
opción de tabla CHECKSUM=1 ,
actualmente sólo soportado por tablas
MyISAM . Consulte

Sección 13.1.5, ?Sintaxis de CREATE
TABLE?.

En modo EXTENDED la tabla
completa se lee registro a registro y se calcula el
checksum. Esto puede ser muy lento para tablas grandes.

Por defecto, si no se especifica ni
QUICK ni EXTENDED ,
MySQL retorna un checksum en vivo si el motor de tabla lo
soporta y escanea la tabla de otro modo.

CHECKSUM TABLE retorna
NULL para tablas no existentes.
Desde MySQL 5.0.3, se genera una advertencia para esta
condición.

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

OPTIMIZE TABLE debe usarse
si ha borrado una gran parte de la tabla o si ha hecho
varios cambios en una tabla con registros de longitud
variable (tablas que tienen columnas
VARCHAR, BLOB, o
TEXT ). Los registros borrados
se mantienen en una lista enlazada y operaciones
INSERT posteriores reúsan
posiciones de antiguos registros. Puede usar
OPTIMIZE TABLE para reclamar el
usuario no usado y para defragmentar el fichero de datos.


En la mayoría de inicializaciones, no necesita ejecutar
OPTIMIZE TABLE para nada.
Incluso si hace muchas actualizaciones a registros de
longitud variables, no es probable que necesite hacerlo más
de una vez a la semana o mes y sólo en ciertas tablas.

Actualmente, OPTIMIZE TABLE
funciona sólo en tablas MyISAM,
BDB y
InnoDB .

Para tablas MyISAM ,
OPTIMIZE TABLE funciona como
sigue:

Para tablas BDB ,
OPTIMIZE TABLE es mapea como
ANALYZE TABLE. Para tablas
InnoDB , se mapea con
ALTER TABLE, que reconstruye la
tabla. Reconstruye las estadísticas actualizadas de índice y
libera espacio no usado en el índice clusterizado. Consulte

Sección 13.5.2.1, ?Sintaxis de ANALYZE
TABLE?.

Puede hacer que OPTIMIZE TABLE
funcione con otros tipos de tabla arrancando
mysqld con la opción
--skip-new o
--safe-mode ; en este caso
OPTIMIZE TABLE se mapea con
ALTER TABLE.

Tenga en ceunta que MySQL bloquea la tabla mientras se
ejecuta OPTIMIZE TABLE .

En MySQL 5.0, los comandos OPTIMIZE
TABLE se escriben en el log binario a no ser que la
palabra NO_WRITE_TO_BINLOG
opcional(o su alias LOCAL) se
use. Esto se hace para que los comandos
OPTIMIZE TABLE se usen en MySQL
server actuando como maestro de replicación se replique por
defecto en el esclavo de replicación.

REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE

    tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE repara una
tabla posiblemente corrupta. Por defecto, tiene el mismo
efecto que myisamchk --recover
tbl_name.
REPAIR TABLE funciona sólo en
tablas MyISAM.

Normalmente nunca debe ejecutar este comando. Sin
embargo, si hay un desastre, REPAIR
TABLE puede recuperar todos los datos de una tabla
MyISAM . Si sus tablas se
corrompen a menudo, debe intentar encontrar la razón de lo
que lo causa, para eliminar la necesidad de usar
REPAIR TABLE. Consulte

Sección A.4.2, ?Qué hacer si MySQL sigue fallando
(crashing)?. Consulte

Sección 14.1.4, ?Problemas en tablas
MyISAM?.

El comando retorna una tabla con las siguientes columnas:


El comando REPAIR TABLE
puede producir muchos registros de información para cada
tabla reparada. El último registro tiene un valor
Msg_type de
status y
Msg_test normalmente debe ser
OK. Si no obtiene OK,
debe intentar reparar la tabla con
myisamchk --safe-recover, ya que
REPAIR TABLE no implementa
todas las opciones de myisamchk.
Plaenamos hacerlo más flexible en el futuro.

Si se da QUICK ,
REPAIR TABLE intenta reparar
sólo el árbol índice. Este tipo de reparación es como lo que
hace myisamchk --recover --quick.


Si usa EXTENDED, MySQL crea
el índice registro a registro en lugar de crear un índice a
la vez ordenando. Este tipo de reparación es como el hecho
por myisamchk --safe-recover.


También hay un modo USE_FRM
disponible en MySQL 5.0 para REPAIR
TABLE. Use esto si el fichero índice
.MYI no existe o su cabecera
está corrupta. En este modo, MySQL recrea el fichero
.MYI usando información desde
el fichero .frm . Este tipo de
reparación no puede hacerse con
myisamchk. Nota:
Use este modo sólo
si no puede usar modos REPAIR
normalmente. La cabecera .MYI
contiene información importante de metadatos (en particular,
los valores actuales AUTO_INCREMENT
y Delete link) que se pierden
en REPAIR ... USE_FRM. No use
USE_FRM si la tabla está
comprimida, ya que esta información se almacena en el
fichero .MYI .

En MySQL 5.0, los comandos REPAIR
TABLE se escriben en el log binario a no ser que la
palabra opcional NO_WRITE_TO_BINLOG
(o su alias LOCAL) se use.

Atención: Si
el servidor muere durante una operación
REPAIR TABLE, es esencial tras
restaurarla que inmediatamente ejecute otro comando
REPAIR TABLE para la tabla
antes de realizar cualquier otra operación en ella. (Siempre
es una buena idea empezar haciendo una copia de seguridad.)
En el peor caso, puede tener un nuevo fichero índice limpio
sin información acerca del fichero de datos, y luego la
siguiente operación que realice puede sobreescribir el
fichero de datos. Este es un escenario improbable pero
posible.

RESTORE TABLE tbl_name [, tbl_name] ... FROM '/path/to/backup/directory'

Restaura la tabla o tablas de una copia de seguridad que
se hizo con BACKUP TABLE. Las
tablas existentes no se sobreescriben; si trata restaurar
una tabla existente, obtiene un error. Pero como
BACKUP TABLE,
RESTORE TABLE actualmente
funciona sólo para tablas MyISAM
. El directorio debe especificarse como una ruta completa.


La copia de seguridad para cada tabla consiste en su
fichero de formato .frm y
fichero de datos .MYD . La
operación de restauración restaura aquellos ficheros, luego
los usa para reconstruir el fichero índice
.MYI. La restauración tarda
más tiempo que la copia de seguridad debido a la necesidad
de reescribir los índices. Mientras más índices tenga la
tabla, más tarda.

El comando retorna una tabla con las siguientes columnas: