mysqldump 能完整导出 InnoDB 全文索引定义和数据，但恢复后倒排表不会自动重建，需执行 OPTIMIZE TABLE 强制刷新；全文索引依赖隐式 FTS_DOC_ID 连续性，跨版本迁移或错误参数（如 --skip-triggers）会导致失效。
MySQL 的 Innodb 全文索引数据在 mysqldump 备份中默认是完整保留的，但恢复后可能无法立即生效——这不是备份丢失，而是索引重建机制未被触发。
mysqldump 能否导出 Innodb 全文索引定义和数据
可以，且无需额外参数。mysqldump 导出的是逻辑 SQL，包含 CREATE TABLE 语句中的 FULLTEXT KEY 定义，以及所有行数据。只要表结构里写了 FULLTEXT(col)，导出文件里就有；插入的数据也一并生成 INSERT 语句。
常见误判现象：
– 恢复后执行 SELECT ... MATCH() AGAINST() 返回空结果
– SHOW INDEX FROM tbl 显示全文索引存在，但搜索无命中
原因不是备份没导出，而是 Innodb 全文索引的倒排表（inverted index）在恢复时不会自动重建，必须等后续 DML 触发或手动优化。
- 仅用
mysqldump+mysql恢复，不会重建全文索引内部结构 -
--single-transaction和--routines等参数对全文索引导出无影响 - 如果原表有大量数据，倒排表重建可能延迟数分钟甚至更久（取决于数据量和 I/O）
恢复后全文索引不生效的强制重建方法
不能依赖“等它自己建”，必须主动干预。最可靠方式是执行 OPTIMIZE TABLE：
OPTIMIZE TABLE your_fulltext_table;
该命令会重建表并强制刷新全文索引的内部结构（包括 FTS_DOC_ID、FTS_INDEX_TABLE 等隐藏表）。注意：
- 执行期间表会被锁（Innodb 行级锁，但全文重建阶段可能升为表级）
- 需确保磁盘空间充足——临时表大小 ≈ 原表数据量 × 1.2
- 不支持在只读实例或从库上执行（会报错
ERROR 1788） - 替代方案
ALTER TABLE ... ENGINE=InnoDB效果相同，但更重，不推荐
增量备份中全文索引变更如何捕获
Binlog 不记录全文索引的内部更新（如倒排表行插入），只记录原始 DML（INSERT/UPDATE/DELETE）。这意味着：
- 用
mysqlbinlog回放日志后，全文索引仍需手动OPTIMIZE TABLE - 如果某次
UPDATE修改了全文字段，binlog 里只有那条语句，没有“同步更新倒排表”的附加操作 - 基于时间点恢复（
--start-datetime）后，必须把涉及全文表全部OPTIMIZE一遍，否则搜索结果不一致 -
innodb_ft_cache_size或innodb_ft_total_cache_size等配置变更不会写入 binlog，需在目标实例手动同步
真正要警惕的冷门限制
全文索引备份本身没问题，问题出在“隐式依赖”上——它依赖 FTS_DOC_ID 列的连续性和正确性。而这个列：
- 是隐藏的、自增的、不可见的，但
mysqldump不导出它的值（只导出数据行） - 恢复后，Innodb 会从当前最大
FTS_DOC_ID继续分配，若原表曾大量删改，可能导致 ID 空洞或重复风险 - 跨版本迁移（如 5.7 → 8.0）时，8.0 默认启用
innodb_ft_enable_stopword，若原库关了停用词，恢复后搜索行为会变 - 不要用
--skip-triggers或--no-create-info备份含全文索引的表，否则建表语句缺失FULLTEXT，索引直接消失
最易被忽略的一点：备份脚本里加了 --single-transaction，却忘了检查事务隔离级别是否为 REPEATABLE READ——否则并发 DML 可能导致全文字段值与 FTS_DOC_ID 映射错位，恢复后搜索返回错误文档。
