全文索引专为大段文本的语义/关键词搜索设计，适用于MATCH() AGAINST()等场景；不适用于=、LIKE '%xxx'等精确或前缀匹配，此时应选B-Tree索引。
SQL 中的文本字段索引，尤其是全文索引（Full-Text Index），不是用来加速 = 或 LIKE '%xxx' 这类简单匹配的，而是专为“在大段文本中按语义或关键词查找”而设计的。它适用于内容搜索场景，而非结构化精确查询。
适合用全文索引的场景
当你的表里有 TEXT、VARCHAR（长度较大）、NVARCHAR 类型字段，且业务需要支持以下操作时，全文索引更合适：
- 用户在文章标题或正文里搜“人工智能”，希望同时匹配“AI”“机器学习”（依赖词干、同义词或配置）
- 电商商品描述中搜索“防水 蓝牙 耳机”，返回含全部三个词（或部分相关词）的商品，不依赖固定顺序
- 日志表中快速定位包含“timeout”且紧邻“database”的记录（支持邻近搜索
NEAR） - 新闻库中按“最近7天 + 含‘政策’但不含‘草案’”进行筛选（支持布尔逻辑 + 时间范围组合）
不适合用全文索引的情况
如果只是做等值判断、前缀匹配或结构化过滤，全文索引不仅没优势，反而增加维护成本和查询延迟：
- 查用户昵称是否等于
'zhangsan'→ 用普通 B-Tree 索引即可 - 查邮箱以
'gmail.com'结尾 →INDEX(email) + WHERE email LIKE '%@gmail.com'更高效（注意：后缀匹配无法用常规索引，但全文索引也不适用） - 订单状态字段是
ENUM('pending','paid','shipped')→ 完全不需要全文索引 - 字段平均长度只有 20 字符，且几乎都是唯一值 → 全文索引的倒排表开销远超收益
不同数据库的实现差异要点
全文索引不是 SQL 标准功能，各数据库实现机制和能力差别明显：
-
MySQL：需使用
MyISAM或InnoDB（5.6+），建索引用FULLTEXT(title, content)；查询用MATCH() AGAINST()，支持自然语言模式和布尔模式 -
PostgreSQL：靠
tsvector+tsquery实现，需配合to_tsvector()和@@操作符；可自定义字典、停用词、分词器（如中文需额外扩展zhparser） -
SQL Server：需单独启用全文搜索服务，创建全文目录和索引；查询用
CONTAINS()或FREETEXT()，支持权重、相似性排名 -
SQLite：通过 FTS5（或旧版 FTS4）虚拟表实现，查询语法类似
WHERE content MATCH 'python AND tutorial'
使用前必须确认的关键点
避免上线后才发现不可用，建全文索引前建议检查：
- 目标字段是否允许
NULL？多数数据库要求全文索引列不能为 NULL（或需设默认值） - 字符集是否支持分词？比如 MySQL 的 utf8mb4 是必须的，gbk 可能导致中文分词失败
- 是否已处理停用词？默认会忽略“的”“了”“and”“the”等高频无意义词，若业务需要保留，得手动调整配置
- 增量更新是否及时？InnoDB 全文索引有缓存机制，新插入数据可能延迟数秒才进入索引（可调
innodb_ft_cache_size）
不复杂但容易忽略。选对索引类型，比优化单条 SQL 更影响搜索体验。
