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降低碎片；超大表考虑分区级重建，而非整库重建
