mysql全文索引用倒排索引替代b+树，通过“词→文档”映射跳过全表扫描；match()能避开全表扫描因其直接查询词元到文档id的映射表，前提是索引存在且查询词未被ft_min_word_len或停用词过滤。
MySQL全文索引不是“让LIKE变快”的补丁，而是彻底换了一套索引逻辑——它用倒排索引替代B+树，把“找包含‘数据库’的行”变成“查‘数据库’这个词指向哪些行”，跳过全表扫描，这才是解决海量文本搜索的根本路径。
为什么MATCH()能避开全表扫描？
传统LIKE '%数据库%'无法走任何B+树索引，因为前导通配符破坏了有序性；而MATCH() ... AGAINST()直接命中倒排索引的词元（Term）→文档ID映射表，查询耗时与总数据量无关，只和匹配到的文档数量相关。
关键前提是：索引必须已存在，且查询词未被过滤（比如长度低于ft_min_word_len或命中停用词）。
- 倒排索引内部由6张辅助表管理（如
fts_0000000000000001_0000000000000002_index），不暴露给用户，但会占用额外磁盘空间 - InnoDB全文索引要求MySQL ≥ 5.6，MyISAM虽更早支持，但无事务保障，生产环境基本不用
- 索引构建是异步的：INSERT/UPDATE后不会立即更新倒排索引，有毫秒级延迟（可调
innodb_ft_aux_table观察）
中文搜索必须加ngram解析器
默认分词器按空格/标点切分，对“MySQL教程很实用”有效，但对“数据库优化指南”完全失效——它只会当一个长词处理，而ft_min_word_len默认为4，导致“数据库”（3字）、“优化”（2字）全被丢弃。
安全的随机密码生成器。支持自定义长度、字符类型（大写/小写字母、数字、特殊符号），排除相似字符，批量生成。纯 Python 标准库，无需 API 密钥。
WITH PARSER ngram强制按固定长度（默认n=2）滑动切分：“数据库”→“数据”“库优”“优化”，这才让短中文词可搜。
- ngram分词不可逆，搜索“数据库”能命中，“数”或“据库”也能意外命中（这是代价）
- 若需更高精度，得上Elasticsearch或外部中文分词插件，MySQL原生不支持jieba类语义分词
- 创建ngram索引后，
ft_min_word_len失效，最小分词单位就是ngram的n值（通常2）
自然语言模式 vs 布尔模式：别混用场景
IN NATURAL LANGUAGE MODE（默认）适合用户直接输关键词，比如搜索框输入“MySQL 性能优化”，MySQL自动做停用词过滤、相关性打分、词干还原；而IN BOOLEAN MODE是给开发者用的精确控制语法，比如+'事务' -'隔离级别'。
- 自然语言模式下，
AGAINST('a b c')等价于“a OR b OR c”，不支持+/-操作符，写了也报错 - 布尔模式下，不计算相关性分数，
MATCH() AGAINST()返回0或1，想排序得自己加逻辑 - 两种模式不能同时用，
AGAINST('xxx' IN NATURAL LANGUAGE MODE) OR AGAINST('yyy' IN BOOLEAN MODE)是非法SQL
容易被忽略的性能陷阱
全文索引不是银弹——它加速查询，但拖慢写入，且对小数据集反而更慢。
- 每条INSERT/UPDATE都要触发分词+倒排索引更新，写入吞吐比普通表低15%~30%
- 少于1万行的表，
LIKE可能比全文索引还快，因为倒排索引初始化成本高 -
MATCH()字段列表必须和FULLTEXT定义完全一致，MATCH(title)查只有FULLTEXT(title, content)的索引会失败 - 相关性分数（relevance）只在自然语言模式下有意义，布尔模式返回的是布尔结果，不是分数
真正卡住人的往往不是“怎么建索引”，而是没意识到：中文分词依赖ngram、写入延迟不可控、小表加全文索引反降效、以及MATCH字段必须严格对齐——这些细节漏掉一个，查询就静默失败或返回空。
