CONTAINS查不到结果八成是全文索引未生效，需确认数据库启用全文搜索、目标列显式加入索引且sys.fulltext_index_columns中is_enabled=1。
CONTAINS 查不到结果，八成不是 SQL 写错了，而是全文索引根本没生效。
检查全文索引是否真正覆盖目标列
SQL Server 的 CONTAINS 不是“建了目录就能用”，必须同时满足三个硬性条件：数据库启用全文搜索、目标列显式加入全文索引、该列在 sys.fulltext_index_columns 中 is_enabled = 1。
- 运行检查语句：
SELECT object_name(object_id) AS table_name, column_name, is_enabled FROM sys.fulltext_index_columns ftc JOIN sys.columns c ON ftc.column_id = c.column_id AND ftc.object_id = c.object_id WHERE ftc.object_id = OBJECT_ID('YourTable'); - 如果查不到记录，说明列没进索引——先执行
DROP FULLTEXT INDEX ON YourTable，再用CREATE FULLTEXT INDEX显式添加列 - 注意类型限制：
text/ntext已弃用；xml列不支持CONTAINS；只支持char/varchar/nchar/nvarchar/varbinary(max)（含 FILESTREAM）
存储过程里传参必须防注入 + 避免参数嗅探
直接拼接用户输入到 CONTAINS 第二个参数，等于给 SQL 注入开后门；更隐蔽的是参数嗅探：首次传短词（如 N'a'）生成的执行计划，后续传长句（如 N'数据库性能调优方案'）就会卡住。
- 基础转义用
QUOTENAME(@searchTerm, '''')，再套一层REPLACE(, '''', '''''')处理嵌套单引号 - 前缀搜索（如
"数据库*"）需手动拼通配符，不能依赖用户原样输入 - 加
OPTION (RECOMPILE)强制每次重编译，尤其适合搜索词长度/分布差异大的场景 - 安全写法示例：
DECLARE @searchTerm NVARCHAR(100) = N'数据库优化'; DECLARE @containsClause NVARCHAR(200) = N'"' + REPLACE(QUOTENAME(@searchTerm, ''''), '''', '''''') + N'"'; SELECT id, title FROM Articles WHERE CONTAINS(content, @containsClause) OPTION (RECOMPILE);
避免 SELECT * 导致 IO 爆炸
全文索引只加速匹配判断，不存原始值。SQL Server 必须根据匹配行 ID 回查聚集索引取其他字段——如果返回几十个字段，匹配行上千，磁盘 IO 就会直线上升。
- 只
SELECT真正需要的字段，尤其是避开varbinary(max)或大文本列 - 别用
SELECT *，哪怕只是临时调试 - 若需高亮或摘要，应在应用层处理，不在存储过程中做字符串截取或 XML 解析
- 中文搜索务必指定语言 ID：
CONTAINS(content, ' "数据库" ', LANGUAGE 2052)
CONTAINS 和 FREETEXT 别混用
语义差异直接影响召回率：CONTAINS 是精确匹配词干+同义词（依赖语言统计），适合结构化搜索；FREETEXT 会自动拆词、忽略停用词、加权相似度，更适合自然语言问句。
- 搜
"sql server 安装"，CONTAINS默认只匹配完整短语或带通配符变体（"sql*"），而FREETEXT可能命中"SQL Server setup"或"install SQL" - 但
FREETEXT无法控制权重，也不能用布尔逻辑（AND/OR） - 线上业务若要求结果可控，优先用
CONTAINS+ 手动分词；客服问答类场景才考虑FREETEXT
最容易被忽略的是：全文索引状态和列启用标志必须实时验证，而不是靠“我记得建过了”；另外，OPTION (RECOMPILE) 在高并发下有编译开销，但比固化低效计划更可控——这点常被跳过测试直接上线。
