MySQL 8.0 的 InnoDB 全文索引核心增强是原生支持并默认启用 ngram 分词器，实现中文按字切分；支持动态调整分词粒度参数、布尔模式下支持±和*通配符，并可与B+树索引混合使用。
MySQL 8.0 的 InnoDB 全文索引到底加了什么
MySQL 8.0 并没有“重写”全文检索，而是补上了 InnoDB 在 5.6–7.x 阶段长期缺失的生产就绪能力。最核心的增强是 ngram 分词器正式成为 InnoDB 原生支持的解析器，且默认启用——这意味着中文字段无需额外配置分词服务，建索引时指定 WITH PARSER ngram 就能按字（非词）切分。
其他关键改进包括：
-
innodb_ft_min_token_size和innodb_ft_max_token_size可动态调整（之前需重启），影响中文单字/双字匹配粒度 -
MATCH() AGAINST()在布尔模式下支持+/-和通配符*，但不支持模糊匹配（如~2）或编辑距离 - 全文索引现在可与普通 B+树索引共存于同一列，
WHERE条件中能混合使用MATCH和=、IN等谓词，优化器会尝试合并执行计划
为什么你仍不该用 MySQL 全文索引替代 Elasticsearch
不是功能“不够”，而是设计目标不同：MySQL 的全文索引本质是「带文本语义的二级索引」，服务于事务型查询；Elasticsearch 是「以搜索为中心的存储引擎」，所有设计都围绕倒排索引生命周期展开。
典型差异点：
- 分词控制：MySQL 的
ngram只能按固定长度切分（如 2 字），无法做同义词扩展、停用词过滤或拼音转换；ES 的analyzer可组合ik_smart+synonym+pinyin插件链 - 排序与打分：MySQL 返回结果默认无相关性排序（自然语言模式除外），
AGAINST('a b', IN NATURAL LANGUAGE MODE)才返回隐式分数，但不可干预权重；ES 默认基于 TF-IDF + BM25 打分，且支持function_score自定义 - 更新延迟：MySQL 全文索引随事务实时更新，但大文档插入可能触发后台同步（
innodb_optimize_fulltext_only控制）；ES 默认 1 秒 refresh 延迟，可控但非强一致
什么时候该坚持用 MySQL 全文索引
当你的搜索需求满足以下全部条件时，加 FULLTEXT 索引是最轻量、最安全的选择：
- 数据量在百万级以内（实测：InnoDB 全文索引在 500 万行
TEXT字段上，MATCH AGAINST平均响应 ） - 只查标题、短描述等结构清晰的字段，不涉及长日志、评论流等高噪声文本
- 不需要高亮、聚合、facet、地理位置联合筛选等复杂能力
- 业务已重度依赖 MySQL 事务一致性，无法接受双写或异步同步带来的延迟与不一致风险
例如后台管理系统的「文章标题关键词搜索」，直接 ALTER TABLE posts ADD FULLTEXT(title) WITH PARSER ngram，然后 SELECT * FROM posts WHERE MATCH(title) AGAINST('监控告警' IN BOOLEAN MODE) 即可上线。
Elasticsearch 同步到 MySQL 的常见翻车点
很多人想“用 ES 搜，用 MySQL 存”，结果卡在数据同步环节。最容易被忽略的是：
- Binlog 格式必须为
ROW，且binlog_row_image=FULL，否则 Canal/Debezium 拿不到完整字段值，导致 ES 文档缺字段 - MySQL 中
TINYINT(1)常被 ORM 映射为布尔值，但 ES 接收时若未显式声明"type": "boolean"，会当成字符串索引，后续term查询失败 - ES 的
refresh_interval设为-1关闭自动刷新后，忘了在批量导入后手动调POST /my_index/_refresh，查不到新数据还以为同步失败 - 没限制 MySQL 全文索引的最小词长（
innodb_ft_min_token_size=1），导致单个汉字也能被索引，但 ES 的ngramtokenizer 默认从 2 开始，两边分词结果对不上，召回率骤降
真正难的从来不是“能不能搜”，而是“搜得准不准”和“数据对不对得上”。MySQL 全文索引省事，但边界清晰；Elasticsearch 强大，但每层抽象都在增加出错概率。
