乐趣区

关于mysql:MySql-全文索引-导致查询效率问题

场景形容

业务零碎因须要晋升查问效率,思考应用全文索引进行查问,故建设全文索引
全文索引建设后,应用索引查问效率显著晋升,然而过了几天后,查问变得十分迟缓,查问一次数据须要 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

至此大抵起因演绎为

  1. 全文索引所在列,每天更新量十分大,而全文索引中的 update,理论是 insert + delete 操作,delete 的数据会寄存在 INNODB_FT_DELETED 表中,而全文索引的索引数据不会扭转
  2. MySql 这样设定的起因是为了防止数据删除后保护索引的微小代价,每当进行查问的时候,会优先过滤 INNODB_FT_DELETED 中的数据,再进行查问
  3. 当进行了 OPTIMIZE TABLE 操作后,能力 remove 这部分数据

踩坑总结

全文索引并不适宜大数据量更新或删除的场景,可能导致查问效率更慢,且解决时须要 DBA 手动重建表,生产环境危险大

退出移动版