Avez-vous fait SHOW TABLE STATUS avant et après votre drop+rebuild ? Index_length change-t-il beaucoup ? Probablement pas même d'un facteur deux.
Je ne recommande presque jamais de reconstruire quoi que ce soit dans InnoDB. Ça ne vaut pas le coup. Une exception flagrante concerne FULLTEXT index.
Oui le mannequin ALTER reconstruira les index. Il en va de même pour OPTIMIZE TABLE . Les deux "défragmenteront" (dans une certaine mesure) l'index secondaire BTree et le BTree principal (qui contient les données et PRIMARY KEY ).
Les statistiques peuvent être beaucoup mis à jour à moindre coût en utilisant simplement ANALYZE TABLE . Même cela n'est pas souvent nécessaire. 5.6 a une bien meilleure façon de maintenir les statistiques.
Si vous n'utilisez pas déjà innodb_file_per_table=ON , je vous suggère de définir cela (SET GLOBAL ... ) et faites ALTER TABLE tbl ENGINE=InnoDB; une dernière fois.
Modification en ligne
Pour changer ft_* , vous devez reconstruire l'index. Cela implique un ALTER (ou OPTIMIZE , qui est implémenté en tant que ALTER ). Les nouvelles versions de MySQL ont ALGORITHM=INPLACE qui fait ALTER avoir peu ou pas d'impact sur le système en cours d'exécution. Mais, il y a des limites. Consultez le manuel.
Une alternative à un ALTER non INPLACE est pt-query-digest ou gh-ost . Voyez si l'un d'eux fonctionnera pour votre cas.
À moins de "reconstruire la table", vous pouvez DROP INDEX ... et ADD INDEX ... . Encore une fois, je ne sais pas si cela fonctionne pour les index FT "en place". Quoi qu'il en soit, vous perdriez l'utilisation de cet index pendant le processus.
