Você está fazendo SHOW TABLE STATUS antes e depois do seu drop+rebuild? O Index_length muda muito? Provavelmente nem por um fator de dois.

Eu quase nunca recomendo reconstruir nada no InnoDB. Não vale a pena. Uma exceção gritante tem a ver com FULLTEXT índices.

Sim, o ALTER fictício irá reconstruir os índices. Assim como OPTIMIZE TABLE . Ambos irão "desfragmentar" (até certo ponto) o índice secundário BTrees e o BTree principal (que contém os dados e a PRIMARY KEY ).

As estatísticas podem ser muito atualizado mais barato usando apenas ANALYZE TABLE . Mesmo isso nem sempre é necessário. 5.6 tem uma maneira muito melhor de manter as estatísticas.

Se você ainda não estiver usando innodb_file_per_table=ON , sugiro que você defina isso (SET GLOBAL ... ) e faça ALTER TABLE tbl ENGINE=InnoDB; uma última vez.

Alteração on-line

Para alterar ft_* , você precisa reconstruir o índice. Isso implica um ALTER (ou OPTIMIZE , que é implementado como ALTER ). Versões mais recentes do MySQL têm ALGORITHM=INPLACE o que torna ALTER têm pouco ou nenhum impacto no sistema em execução. Mas, existem limitações. Verifique o manual.

Uma alternativa para um ALTER não INPLACE é pt-query-digest ou gh-ost . Veja se algum deles funcionará para o seu caso.

Além de "reconstruir a tabela", você pode DROP INDEX ... e ADD INDEX ... . Novamente, não sei se eles funcionam para índices FT "inplace". De qualquer forma, você perderia o uso desse índice durante o processo.