contains查不到数据需同时满足三条件：表启用全文索引、目标列已加入索引、列类型为char/varchar/nchar/nvarchar/varbinary(max)（含filestream），xml和text类型不支持或需迁移。

全文索引建好了，CONTAINS 却查不到数据？检查这些硬性前提

SQL Server 的全文检索不是“建完索引就能搜”，CONTAINS 和 FREETEXT 要生效，必须同时满足三个条件：表已启用全文索引、目标列在索引中、且该列的数据类型是 char/varchar/nchar/nvarchar/varbinary(max)（含 FILESTREAM）。常见踩坑点是：建了全文目录和索引，但忘了用 CREATE FULLTEXT INDEX 显式把列加进去；或者对 text 列（已弃用）建索引却没做迁移；又或者列被定义为 xml 类型——它不支持 CONTAINS，得改用 query() 或 value() 配合 XQuery。

存储过程中用 CONTAINS 传参要防注入，也得绕过参数嗅探失效

直接拼接用户输入到 CONTAINS 第二个参数里等于开后门。正确做法是用变量 + QUOTENAME 做基础转义，再套一层 REPLACE 清掉通配符干扰：

DECLARE @searchTerm NVARCHAR(100) = N'数据库优化';
SET @searchTerm = REPLACE(REPLACE(@searchTerm, '"', '""'), '', '\');
-- 然后传入 CONTAINS(col, '"' + @searchTerm + '"');

更关键的是性能问题：CONTAINS 在存储过程中常因参数嗅探导致执行计划固化，尤其当首次调用传的是短词（如“a”），后续传长句就卡住。解决办法是加 OPTION (RECOMPILE)，或拆成两步：先用 sys.dm_fts_parser 验证分词有效性，再执行主查询。

CONTAINS 和 FREETEXT 别混用，语义差异直接影响召回率

CONTAINS 是精确匹配词干+同义词（依赖语言统计），适合结构化搜索；FREETEXT 会自动拆词、忽略停用词、加权相似度，更适合自然语言问句。比如搜 “sql server 安装”，CONTAINS 默认只匹配完整短语或带通配符的变体（"sql*"），而 FREETEXT 可能命中 “SQL Server setup” 或 “install SQL”。但代价是：后者无法控制权重，也不能用布尔逻辑（AND/OR）。线上业务若要求结果可控，优先用 CONTAINS + 手动分词；若做客服问答类场景，才考虑 FREETEXT。

全文检索慢？先看是否触发了回表 + 补全字段的代价

很多人写 SELECT * FROM t WHERE CONTAINS(col, ...)，结果发现比普通 LIKE 还慢。根本原因是：全文索引只加速谓词判断，不存原始值；SQL Server 必须根据匹配的行 ID 回查聚集索引/堆取其他字段——如果返回字段多、匹配行数大，IO 就爆炸。优化路径很直接：

• 只 SELECT 真正需要的列，尤其是避免 * 或大文本字段
• 把高频展示字段加进包含列（ADD COLUMN 到全文索引）——但这会增大索引体积，仅适用于小字段（如 title、status）
• 用 TOP N 限制返回量，并确保排序字段上有普通索引（全文本身不提供排序能力）

全文索引的“快”是相对的，它解决的是“从百万行里筛出 10 行”的问题，不是“把 10 行快速渲染成页面”的问题——后者得靠覆盖索引或应用层缓存兜底。