mysql如何迁移带有全文索引的表_mysql全文索引重建建议

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 默认值变了，老索引词频统计逻辑不兼容 —— 这时候重建不是可选项，是必选项。