场景形容
业务零碎因须要晋升查问效率，思考应用全文索引进行查问，故建设全文索引
全文索引建设后，应用索引查问效率显著晋升，然而过了几天后，查问变得十分迟缓，查问一次数据须要 10 秒以上
应用 alter table xxx engine=innodb 重建表之后，查问效率又复原到刚建设索引时的速度
通过 profile 发现，耗时次要耗费在 FULLTEXT initialization 这个步骤
问题剖析
通过排查业务零碎性能得悉，应用全文索引的表每天更新量微小，通过查看系统文件能够得悉在重建表之前，FTS_XXXX_DELETED.ibd 的容量为 268M，这个文件对应 INNODB_FT_DELETED 表
- 想在数据库中查看该表，须要开启 innodb_ft_aux_table 参数
- 重建表后
- 查阅官网文档能够理解这些文件 & 表的作用
FULLTEXT Index
INFORMATION_SCHEMA INNODB_FT_DELETED
至此大抵起因演绎为
- 全文索引所在列，每天更新量十分大，而全文索引中的 update，理论是 insert + delete 操作，delete 的数据会寄存在 INNODB_FT_DELETED 表中，而全文索引的索引数据不会扭转
- MySql 这样设定的起因是为了防止数据删除后保护索引的微小代价，每当进行查问的时候，会优先过滤 INNODB_FT_DELETED 中的数据，再进行查问
- 当进行了 OPTIMIZE TABLE 操作后，能力 remove 这部分数据
踩坑总结
全文索引并不适宜大数据量更新或删除的场景，可能导致查问效率更慢，且解决时须要 DBA 手动重建表，生产环境危险大