Se você executa o mysqld com a opção
          --skip-external-locking (que é o padrão em
          alguns sistemas, como o Linux), você não pode utilizar com
          segurança o myisamchk para conferir uma
          tabela se o mysqld estiver utilizando a
          mesma tabela. Se você pode ter certeza que ninguém está
          acessando as tabelas através do mysqld
          enquanto você executa o myisamchk, você
          só tem que executar o mysqladmin
          flush-tables antes de iniciar a verificação das
          tabelas. Se você não tem certeza, então você deve desligar
          o mysqld enquanto verifica as tabelas. Se
          você executa o myisamchk enquanto o
          mysqld estiver atualizando as tabelas,
          você pode obter um altera que a tabela está corrompida mesmo
          se não estiver.
        
          Se você não estiver utilizando
          --skip-external-locking, pode usar o
          myisamchk para conferir as tabelas a
          qualquer hora. Enquanto você faz isto, todos os clientes que
          tentarem atualizar a tabela irão esperar até que o
          myisamchk esteja pronto, antes de
          continuar.
        
          Se você utilizar o myisamchk para reparar
          ou otimizar tabelas, você
          DEVE sempre assegurar que o
          servidor mysqld não esteja utilizando a
          tabela (Isto também aplica se você utiliza
          --skip-external-locking). Se você não
          desligar o mysql, você deve, pelo menos,
          fazer um mysqladmin flush-tables antes de
          executar o myisamchk. Suas tabelas
          podem estar corrompidos se o
          servidor e o myisamchk acessarem a tabela
          simultaneamente.
        
Este capítulo descreve como checar e lidar com dados corrompidos nos bancos de dados MySQL. Se suas tabelas corromperem com frequência deve ser encontrada a razão para isto! See Secção A.4.1, “O Que Fazer Se o MySQL Continua Falhando”.
          A seção de tabelas MyISAM contêm motivos
          do porque uma tabela pode estar corrompida. See
          Secção 7.1.3, “Problemas com Tabelas MyISAM”.
        
          Quando se realizar recuperação devido a falhas, é
          importante entender que cada tabela
          nome_tabela em um banco de dados
          corresponde a tres arquivos no diretório do banco de dados:
        
| Arquivo | Propósito | 
| nome_tabela.frm | Arquivo com definições da tabela (form) | 
| nome_tabela.MYD | Arquivo de dados | 
| nome_tabela.MYI | Arquivo de índices | 
Cada um destes três tipos de arquivos está sujeito a corrupção de várias formas, mas problemas ocorrem mais frequentemente em arquivos de dados e índices.
          O myisamchk trabalha criando uma cópia do
          arquivo de dados .MYD linha a linha. Ele
          termina o estágio de reparos removendo o antigo arquivo
          .MYD e renomeando o novo arquivo com nome
          original. Se for utilizada a opção --quick,
          myisamchk não cria um arquivo
          .MYD temporário, mas assume que o
          arquivo .MYD está correto e somente gera
          um novo arquivo índice sem mexer no arquivo de dados. Isto é
          seguro, pois o myisamchk detecta
          automaticamente se o arquivo .MYD está
          corrompido e aborda o reparo neste caso. Você pode também
          fornecer duas opções --quick para o
          myisamchk. Neste caso, o
          myisamchk não aborta em alguns erros (como
          chaves duplicadas) mas tenta resolvê-los modificando o
          arquivo .MYD. Normalmente o uso de duas
          opções --quick é útil somente se você
          tiver muito pouco espaço em disco para realizer um reparo
          normal. Neste caso você deve pelo menos fazer um backup antes
          de executar o myisamchk.
        
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

