sql 全文索引性能取决于设计、配置与查询写法三者协同：需指定正确语言（如 language 2052）、审慎管理停用词、优先使用 contains 精确匹配，并定期维护填充与碎片。
SQL 全文索引不是“建了就快”，关键在设计、配置和查询写法三者配合。忽略语言设置、停用词规则或模糊匹配边界，容易导致查不到、查太慢、或结果不相关。
语言与分词必须对齐
中文搜索效果差，常因全文索引未指定正确的语言（如Chinese (Simplified)），导致按字节切分而非语义分词。SQL Server 默认使用英文分词器，对中文、日文等无空格语言基本无效。
- 创建全文索引时显式指定 LANGUAGE：例如LANGUAGE 2052（简体中文）或LANGUAGE ‘Chinese (Simplified)’
- 确保全文目录的 accent sensitivity 设置与数据一致（带音调 / 不带音调影响拼音检索）
- 验证分词结果：用 sys.dm_fts_parser 检查关键词是否被正确切分，例如SELECT * FROM sys.dm_fts_parser(‘ 数据库优化 ’, 2052, 0, 0)
停用词表要审慎定制
默认停用词表会过滤“的”“是”“在”等高频虚词，但业务文本中这些词可能承载语义（如“在岗培训”“是重点任务”）。盲目启用默认停用词，等于主动丢弃关键匹配项。
- 先用 sys.fulltext_stopwords 查看当前停用词；对核心业务字段，建议创建专用停用词表并清空或仅保留极少数干扰词
- 若需保留所有词，可将停用词列表设为 SYSTEM 或OFF（SQL Server 2016+ 支持STOPLIST = OFF）
- 修改停用词后，必须重建全文索引才能生效，不可仅刷新
查询语法决定召回与精度平衡
用 CONTAINS 还是 FREETEXT？前者精确可控，后者自动扩展同义、变形，但易泛化。实际场景中，多数系统应优先用CONTAINS 配合通配符和布尔逻辑。
- CONTAINS(col, ‘” 数据库 ” AND “ 优化 ”‘)：要求同时出现，支持短语 + 布尔
- CONTAINS(col, ‘” 数 *”‘)：前缀匹配，比 LIKE 更高效（利用倒排索引）
- 避免滥用 FREETEXT，它会隐式做词干提取、同义扩展，结果不可预测；如需扩展，改用THESAURUS 手动控制
- 对高亮或排序需求，搭配 CONTAINSTABLE 或FREETEXTTABLE，用 RANK 字段排序
维护与监控不能只靠“自动”
全文索引不会自我优化。增量填充滞后、碎片过高、统计信息陈旧，都会让查询退化为表扫描。
- 设置定期ALTER FULLTEXT INDEX …… START UPDATE POPULATION（增量）或START FULL POPULATION（全量），尤其在大批量导入后
- 监控填充状态：sys.dm_fts_index_population查是否卡住；sys.dm_fts_population_ranges看分段进度
- 每月执行 ALTER FULLTEXT INDEX …… REORGANIZE 降低碎片；超大表考虑分区级重建，而非整库重建
