like仅在小数据量（如10万行以内）且为前缀匹配（如'abc%'）并配合b-tree索引时可凑合使用；否则应优先用fulltext或locate等替代方案。
MySQL 文本搜索性能优化的核心判断是：数据量超过 10 万行后，MATCH() ... AGAINST() 几乎总是比 LIKE 快一个数量级以上，但前提是 FULLTEXT 索引已正确建立且查询方式匹配其语义。
什么时候 LIKE 还能凑合用
小数据量（LIKE 'term%' 可走 B+ 树索引，响应稳定在毫秒内。比如用户输入“订单号：ORD-202”，查 order_no LIKE 'ORD-202%' 就很合适。
- 必须确保该列上有普通 B+ 树索引，否则
LIKE '%term'或LIKE '%term%'一定全表扫描 - 中文或日文等多字节字符需注意排序规则（如
utf8mb4_0900_as_cs），否则大小写或重音敏感可能出错 - MySQL 8.0+ 支持函数索引，可对
LOWER(title)建索引，再配合LOWER(title) LIKE LOWER('xxx%')实现大小写不敏感前缀查
MATCH() ... AGAINST() 的硬性前提和常见失效点
不是建了 FULLTEXT 索引就自动变快——MATCH() ... AGAINST() 有明确的语义边界和配置依赖：
- 必须是
InnoDB表（MySQL 5.6+）或MyISAM表；MEMORY或分区表不支持 - 字段类型只能是
CHAR、VARCHAR、TEXT；JSON或BLOB列不能直接参与全文索引 - 默认停用词（如 “的”、“和”、“in”）会被忽略，若业务关键词恰好是停用词，需自定义
innodb_ft_default_stopword表并重启或重建索引 -
AGAINST('keyword' IN NATURAL LANGUAGE MODE)不支持通配符；要用IN BOOLEAN MODE才能写+'robot*'，但此时不会自动计算相关性得分
真实场景下怎么选：看查询意图，不是看“模糊”还是“精确”
很多人误以为“模糊搜就用 LIKE，全文搜就用 MATCH”，其实关键在语义：
- 查“标题含‘AI’且正文含‘部署’” → 用
MATCH(title) AGAINST('+AI' IN BOOLEAN MODE)和MATCH(content) AGAINST('+部署' IN BOOLEAN MODE)组合，比两个LIKE+AND快 5–20 倍（百万级数据） - 查“以‘2026’开头的流水号” → 用
流水号 LIKE '2026%'，MATCH对这种结构化前缀毫无优势，还强制分词 - 查“用户输入一整句，如‘怎么把 MySQL 全文索引优化到 10ms 内’” → 必须用
NATURAL LANGUAGE MODE，靠 TF-IDF 排序，LIKE完全无法处理语义连贯性
OPTIMIZE TABLE 对全文索引不是可选项，而是延迟生效开关
向已有 FULLTEXT 索引的表插入新行后，新增词只进 INNODB_FT_INDEX_CACHE，不立刻合并进主索引。这意味着新数据可能搜不到，直到你执行：
OPTIMIZE TABLE your_table_name;
这个操作会触发索引合并，但代价高（锁表、IO 密集）。生产环境更稳妥的做法是：
- 批量导入后集中
OPTIMIZE，而非每条 INSERT 后都跑 - 设置
innodb_optimize_fulltext_only = ON避免顺便优化其他索引 - 监控
INNODB_FT_INDEX_CACHE行数，若持续增长说明合并滞后，可能影响搜索覆盖度
最易被忽略的一点：FULLTEXT 索引对单字中文支持差（除非开启 ngram 解析器），而 LIKE '%某字%' 虽慢但至少能命中——这决定了中文站标题搜索是否要混合两种方案。
