¿Has estado haciendo SHOW TABLE STATUS antes y después de su drop+rebuild? ¿Cambia mucho Index_length? Probablemente ni siquiera por un factor de dos.
Casi nunca recomiendo reconstruir nada en InnoDB. Que no vale la pena. Una excepción evidente tiene que ver con FULLTEXT índices.
Sí, el ficticio ALTER reconstruirá los índices. También OPTIMIZE TABLE . Ambos "desfragmentarán" (hasta cierto punto) el índice secundario BTrees y el BTree principal (que contiene los datos y PRIMARY KEY ).
Las estadísticas pueden ser muchas actualizado de manera más económica usando solo ANALYZE TABLE . Incluso eso no es necesario a menudo. 5.6 tiene una forma mucho mejor de mantener las estadísticas.
Si aún no está utilizando innodb_file_per_table=ON , le sugiero que configure eso (SET GLOBAL ... ) y haga ALTER TABLE tbl ENGINE=InnoDB; por última vez.
Alteración en línea
Para cambiar ft_* , necesita reconstruir el índice. Esto implica un ALTER (o OPTIMIZE , que se implementa como ALTER ). Las versiones más nuevas de MySQL tienen ALGORITHM=INPLACE lo que hace ALTER tienen poco o ningún impacto en el sistema en ejecución. Pero, hay limitaciones. Consulta el manual.
Una alternativa a un ALTER no INPLACE es pt-query-digest o gh-ost . Vea si alguno de ellos funcionará para su caso.
Aparte de "reconstruir la tabla", puede DROP INDEX ... y ADD INDEX ... . Nuevamente, no sé si estos funcionan para los índices FT "in situ". De todos modos, perdería el uso de ese índice durante el proceso.
