mysqldump 导出时全文索引会丢失吗
不会自动丢失，但默认行为下 mysqldump 不会显式重建全文索引 —— 它只导出表结构和数据，而 FULLTEXT 索引定义虽在 CREATE TABLE 语句里，但某些旧版本（如 MySQL 5.6 之前）或加了 --skip-extended-insert + 手动编辑后容易被删掉。更常见的是：导入目标库时因存储引擎不一致（比如源是 InnoDB，目标误设为 MyISAM）导致全文索引创建失败，错误信息类似 ERROR 1214 (HY000): The used table type doesn't support FULLTEXT indexes。
- 导出前务必确认源表引擎：
SHOW CREATE TABLE t1，检查是否含ENGINE=InnoDB且FULLTEXT字段存在 - 导入前在目标库执行
SELECT VERSION()，确保 ≥ 5.6（InnoDB全文索引自 5.6 起稳定支持） - 避免用
--compatible=mysql323或其他降级兼容参数，它们会剥离FULLTEXT定义
迁移后全文索引不可用？先查这三个地方
迁移完跑 MATCH() AGAINST() 返回空结果，不一定是索引坏了，大概率是配置或状态没同步到位。
- 检查
ft_min_word_len值是否一致：源库若设为 2，目标库仍是默认 4，则所有长度为 2–3 的词无法被索引。查看命令：SHOW VARIABLES LIKE 'ft_min_word_len' - 确认
innodb_ft_enable_stopword开关：设为OFF时停用词表失效，但迁移后若目标库是ON（默认），短词可能被过滤。需手动同步该变量值 - 运行
SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't1' AND INDEX_TYPE = 'FULLTEXT'，验证索引是否真存在于目标表元数据中
什么时候必须重建全文索引
不是每次迁移都要重建，但以下情况跳过重建，后续 AGAINST 查询大概率不准：
- 表从
MyISAM迁到InnoDB（反之亦然）—— 底层分词、停用词处理逻辑不同 - 目标库的
ft_stopword_file指向了空文件或自定义路径，但没重载（需SET GLOBAL innodb_ft_server_stopword_table = 'db/stopwords'+FLUSH TABLES） - 迁移后执行过大量
INSERT/UPDATE但未触发OPTIMIZE TABLE，InnoDB全文索引的变更缓冲区（innodb_ft_cache_size）可能未合并到主索引树
重建命令很简单：ALTER TABLE t1 DROP INDEX ft_idx, ADD FULLTEXT INDEX ft_idx (title, content)。注意别漏掉字段顺序，它影响 MATCH() 的字段列表匹配。
重建全文索引的性能代价有多大
对大表来说，重建不是“秒级操作”。InnoDB 全文索引重建会扫描全表、构建倒排索引、写入辅助表（如 FTS_0000000000000123_0000000000000145_INDEX_1），期间表可读但写入会被阻塞（DDL 锁），且临时磁盘空间可能达原表 1.5 倍。
- 生产环境务必避开高峰；可在从库重建完再主从切换
- 如果只是字段内容变更（非结构迁移），优先用
OPTIMIZE TABLE替代重建 —— 它能合并缓存、刷新脏页，开销小得多 - MySQL 8.0+ 支持在线 DDL（
ALGORITHM=INPLACE），但全文索引重建仍需拷贝表（ALGORITHM=COPY），这点容易误判
真正麻烦的是跨版本迁移（比如 5.7 → 8.0）后发现 innodb_ft_num_word_optimize 默认值变了，老索引词频统计逻辑不兼容 —— 这时候重建不是可选项，是必选项。
