全文索引可将LIKE '%keyword%' 查询性能提升30–50倍，但需正确创建并避开中文分词、停用词、最小词长等限制；其加速本质是倒排索引查文档ID列表，而非逐行字符串匹配。
直接上结论：全文索引能将 LIKE '%keyword%' 这类全表扫描查询的性能提升 30–50 倍，但前提是正确创建、合理使用，并避开中文分词、停用词、最小词长等隐性限制。
为什么 MATCH() AGAINST() 比 LIKE 快得多
根本原因不在“用了索引”，而在于结构差异：LIKE 被迫逐行扫描并做字符串匹配；MATCH() AGAINST() 则查倒排索引——它早把每个有效词映射到了文档 ID 列表，跳过无关行。这就像查字典 vs 通读整本书。
但注意：这个加速只在数据量 ≥10 万条时才明显体现；小表反而可能因索引维护开销略慢。
- MySQL 不会为单字符或双字符词建索引（默认
ft_min_word_len=4），所以搜 "db" 或 "go" 永远命中不了 -
IN NATURAL LANGUAGE MODE会自动过滤停用词（如 "the", "and", "是", "的"），且不支持布尔操作符 - 搜索结果默认按相关性（TF-IDF 计算）降序，无需额外
ORDER BY
创建全文索引必须绕开的三个坑
不是加了 FULLTEXT 关键字就万事大吉。InnoDB 下最容易栽在以下三点：
- 字符集必须统一：组合索引列（如
title,content）需同属utf8mb4且排序规则一致（推荐utf8mb4_0900_as_cs），否则建索引失败并报错ERROR 1214 - 单表仅允许一个全文索引：不能对
title单独建一个，再对content单独建一个；必须合并声明：fulltext(title, content) - TEXT 类型字段不能有前缀长度限制：写成
content text(2000)是非法语法，会直接报错ERROR 1170
布尔模式（boolean mode）才是生产环境主力
自然语言模式适合入门，但实际业务中几乎必用布尔模式——它能精准控制逻辑，且不受停用词和词干提取干扰。
示例语句：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
SELECT * FROM articles
WHERE MATCH(title, content) AGAINST('+mysql +performance -debug' IN BOOLEAN MODE);
含义：必须含 "mysql" 和 "performance"，且排除含 "debug" 的行。
-
+表强制包含，-表强制排除，>/调整权重，~表示负向影响（降低相关性） - 短语搜索用双引号：
AGAINST('"database optimization"' IN BOOLEAN MODE)，此时空格和顺序都参与匹配 - 注意：布尔模式下不返回相关性分数，若需排序，得手动加
ORDER BY MATCH(...) AGAINST(...)
中文文本必须额外处理，否则全文索引基本失效
MySQL 原生不支持中文分词。它把整段中文当做一个超长“单词”，而默认 ft_min_word_len=4，导致大部分中文词（两字、三字词）全被丢弃。
真实后果：你搜 "数据库"，但索引里根本没有这个词元，结果永远为空。
- 临时解法：调低
ft_min_word_len=1并重建索引（需重启 MySQL 或 flush tables），但这会让大量无意义单字（如“的”、“了”）进索引，膨胀体积、拖慢查询 - 可靠方案：改用
ngram插件（MySQL 5.7+ 内置），设ngram_token_size=2后，"数据库" 会被切为 "数据"、"库"（注意边界），效果可控 - 更优路径：把中文分词逻辑前置到应用层（如用 jieba 分词后写入带分隔符的字段），让 MySQL 只负责匹配英文风格的词元
最常被忽略的一点：全文索引不是“开了就快”，它依赖后台的 FTS AUX 表异步合并，高并发写入后搜索可能短暂滞后几秒——别把它当成强一致的精确查询工具。
