不能直接在where子句调用ts_rank()，因其返回float4而非布尔值，且需先通过@@筛选匹配行；正确做法是子查询中用@@过滤，外层计算排名并排序。
为什么不能直接在 WHERE 子句里调用 ts_rank()
因为 ts_rank() 是窗口/聚合类函数，它依赖于已经完成匹配的行集；而 WHERE 执行在排序和投影之前，此时你还没法对“哪些行匹配了”做排名计算。强行写成 WHERE ts_rank(...) > 0.1 会报错：ERROR: argument of WHERE must be type boolean —— 它返回的是 float4，不是布尔值。
常见错误写法：
SELECT * FROM articles
WHERE ts_rank(to_tsvector(title), to_tsquery('postgres')) > 0.05;
这会直接失败。正确路径是：先过滤，再排名，且两者不能混在同一层逻辑中。
tsvector @@ tsquery 必须放在子查询或 CTE 的 WHERE 中
全文匹配判断只能靠 @@ 操作符，它返回 boolean，是唯一能进 WHERE 的全文检索谓词。所有实际检索都得从这里开始。
- 子查询里用
@@筛出候选行，外层再算排名 - 别在子查询里提前
SELECT ts_rank(...)，除非你确定要为每行都计算（哪怕后续被WHERE过滤掉）——这浪费 CPU - 如果字段没建
GIN索引，@@会全表扫描，10 万行以上就明显卡顿
推荐结构：
SELECT id, title, rank
FROM (
SELECT id, title,
ts_rank(to_tsvector('english', title), to_tsquery('english', 'database')) AS rank
FROM articles
WHERE to_tsvector('english', title) @@ to_tsquery('english', 'database')
) ranked
ORDER BY rank DESC;
子查询中语言配置不一致会导致匹配失败
to_tsvector() 和 to_tsquery() 必须用相同语言配置，否则词干归一化规则不同，@@ 判断永远为 false。比如：
-
to_tsvector('english', ...)+to_tsquery('simple', ...)→ 不匹配（english会把 “running” → “run”，simple不处理） - 中文场景必须配
zhparser，不能硬套english—— 否则整段文字被当做一个词，@@失效 - 若字段内容混合中英文，建议统一用
simple配置（禁用停用词和词干），但需接受相关性弱的问题
验证方式：
SELECT to_tsvector('english', 'running') @@ to_tsquery('english', 'run'); -- true
SELECT to_tsvector('english', 'running') @@ to_tsquery('simple', 'run'); -- false
性能陷阱：重复调用 to_tsvector() 会拖慢查询
上面示例里，to_tsvector('english', title) 被调用了两次：一次在 WHERE，一次在 SELECT。PostgreSQL 不会自动缓存中间结果，尤其当 title 是 TEXT 大字段时，开销明显。
更优写法是用 CTE 或子查询把向量化结果固化一次：
WITH vectorized AS (
SELECT id, title,
to_tsvector('english', title) AS doc_tsv
FROM articles
)
SELECT id, title, ts_rank(doc_tsv, to_tsquery('english', 'database')) AS rank
FROM vectorized
WHERE doc_tsv @@ to_tsquery('english', 'database')
ORDER BY rank DESC;
注意：CTE 在 PostgreSQL 中默认是物化的（除非加 MATERIALIZED 显式控制），所以 to_tsvector() 只执行一次。这对长文本或高并发查询很关键。
真正容易被忽略的点是：全文检索不是“写完就能快”，to_tsvector() 的语言配置、索引存在性、子查询层级是否引入冗余计算——这三者任何一个出问题，都会让排名查询从毫秒级退化到秒级。别只盯着 ts_rank() 参数调优，先确保基础链路没断。
