Início / dba / Perguntas / 30922
Accepted
Mike B
Asked: 2012-12-22 10:28:01 +0800 CST

Existe um indicador de progresso para o progresso de OPTIMIZE TABLE?

  • 772

MySQL 5.1.4x (Windows) | InnodbGenericName

Recentemente, limpei os dados de um banco de dados mySQL (algumas centenas de milhares de linhas) e estou planejando usar

OPTIMIZE TABLE LOGTABLEFOO1,LOGTABLEFOO2,LOGTABLEFOO3;

para reduzir a pegada de espaço de dados, o espaço em branco vazio está ocupando no sistema de arquivos.

Minha preocupação é que, assim que iniciar este comando, não saberei quanto tempo levará ou em que ponto do processo. Existe alguma maneira que eu possa determinar esta informação? Tanto quanto eu sei, não há nenhum indicador de progresso.

mysql innodb

3 respostas

  1. Best Answer

    Não há nada que o MySQL tenha que indique o progresso do OPTIMIZE TABLE;.

    Você pode ter que acessar o sistema operacional usando o Windows Explorer e procurar uma tabela tmp crescente. Dica: Tabelas temporárias são tabelas MyISAM que não possuem uma extensão . frmarquivo com o nome #sql-9999.MYDe #sql-9999.MYI. Enquanto esses dois arquivos existirem, a consulta será considerada em andamento. Para saber até que ponto, seria preciso saber quantas linhas vezes o comprimento médio das linhas para estimar a porcentagem feita ou deixada a ser feita.

    MariaDB tem alguma medição de progresso para o seguinte :

    • ALTER TABLE
    • ADD INDEX
    • DROP INDEX
    • LOAD DATA INFILE
    • CHECK TABLE
    • REPAIR TABLE
    • ANALYZE TABLE
    • OPTIMIZE TABLE

    Eu discuti o assunto antes em termos de operações do MySQL

    Se você está tentando reduzir o tamanho de ibdata1 para InnoDB, descartar tabelas simplesmente deixa grandes lacunas em ibdata1. Você deve executar uma limpeza completa da infraestrutura InnoDB.

    ATUALIZAÇÃO 2012-12-21 19:30 EDT

    Como esse banco de dados usa innodb, haverá uma tabela temporária crescente que posso procurar?

    Digamos que você queira correr

    OPTIMIZE TABLE mydb.mytable;

    Veja dois cenários envolvendo innodb_file_per_table e esteOPTIMIZE TABLE

    CENÁRIO #1: innodb_file_per_table desabilitado

    A execução OPTIMIZE TABLEfará com que todos os dados e páginas de índice mydb.mytablesejam anexados contiguamente a ibdata1. Isso deixará o espaço ocupado anteriormente para aumentar ainda mais a loucura da fragmentação.

    Nesse cenário, a tabela temporária existiria como InnoDB e se materializaria em ibdata1. Assim, não haveria nada para monitorar visualmente.

    CENÁRIO #2: innodb_file_per_table ativado

    Para cada tabela InnoDB mydb.mytable você teria

    • /var/lib/mysql/mydb/mytable.frm
    • /var/lib/mysql/mydb/mytable.ibd

    O .ibdarquivo contém os dados e as páginas de índice da tabela.

    A execução OPTIMIZE TABLEfará com que todos os dados e páginas de índice mydb.mytablesejam gravados em um .ibdarquivo externo que você pode ver no Windows Explorer.

    EMBARGO

    Ativar innodb_file_per_table e executar OPTIMIZE TABLEnunca recuperará o espaço anteriormente ocupado em ibdata1. Você terá que realizar a limpeza do InnoDB para recriar o ibdata1 de forma que os dados e índices nunca mais residam no ibdata1.

    CONCLUSÃO

    Como afirmado anteriormente, o MariaDB pode monitorarOPTIMIZE TABLE;

    Se você quiser algo que possa monitorar e tiver innodb_file_per_table ativado, poderá substituir

    OPTIMIZE TABLE LOGTABLEFOO1,LOGTABLEFOO2,LOGTABLEFOO3;

    com o seguinte equivalente mecânico:

    CREATE TABLE LOGTABLEFOO1_NEW LIKE LOGTABLEFOO1;
INSERT INTO LOGTABLEFOO1_NEW SELECT * FROM LOGTABLEFOO1;
ALTER TABLE LOGTABLEFOO1 RENAME LOGTABLEFOO1_OLD;
ALTER TABLE LOGTABLEFOO1_NEW RENAME LOGTABLEFOO1;
DROP TABLE LOGTABLEFOO1_OLD;
ANALYZE TABLE LOGTABLEFOO1;

CREATE TABLE LOGTABLEFOO2_NEW LIKE LOGTABLEFOO2;
INSERT INTO LOGTABLEFOO2_NEW SELECT * FROM LOGTABLEFOO2;
ALTER TABLE LOGTABLEFOO2 RENAME LOGTABLEFOO2_OLD;
ALTER TABLE LOGTABLEFOO2_NEW RENAME LOGTABLEFOO2;
DROP TABLE LOGTABLEFOO2_OLD;
ANALYZE TABLE LOGTABLEFOO2;

CREATE TABLE LOGTABLEFOO3_NEW LIKE LOGTABLEFOO3;
INSERT INTO LOGTABLEFOO3_NEW SELECT * FROM LOGTABLEFOO3;
ALTER TABLE LOGTABLEFOO3 RENAME LOGTABLEFOO3_OLD;
ALTER TABLE LOGTABLEFOO3_NEW RENAME LOGTABLEFOO3;
DROP TABLE LOGTABLEFOO3_OLD;
ANALYZE TABLE LOGTABLEFOO3;

    Tenha em mente que OPTIMIZE TABLE nada mais é ALTER TABLE ... ENGINE=InnoDB;do que ANALYZE TABLE .

    Com essas etapas, você sabe com antecedência quais são as tabelas temporárias

    • LOGTABLEFOO1_NEW.ibd
    • LOGTABLEFOO2_NEW.ibd
    • LOGTABLEFOO3_NEW.ibd

    Simplesmente monitore a existência e o tamanho de cada arquivo até que ele desapareça.

    • 12

  2. Existe uma maneira mais simples, se você tiver acesso ao sistema de arquivos.

    MySQL gera um arquivo .TMD; você pode observar o tamanho do arquivo crescendo; deve atingir mais ou menos o tamanho do seu MYD existente quando terminar.

    Por exemplo, se você cd para o seu datadir, e simplesmente watch "ls -lah|grep table_name"retornará algo assim (no Linux). No meu caso, o progresso é de 287 MB de 427 MB (aproximadamente).

    -rw-rw----.  1 mysql mysql 427M Feb 19 23:45 ticket_change.MYD
-rw-rw----.  1 mysql mysql 541M Feb 20 01:10 ticket_change.MYI
-rw-rw----.  1 mysql mysql 287M Feb 20 01:45 ticket_change.TMD
    • 2

  3. O pt-online-schema-change do Percona Toolkit faz isso para você.

    Altere mydb.LOGTABLEFOO1para InnoDB, executando efetivamente OPTIMIZE TABLEde maneira não bloqueante porque já é uma tabela InnoDB

    pt-online-schema-change --alter "ENGINE=InnoDB" D=mydb,t=LOGTABLEFOO1
    • 1

relate perguntas