tsvector+GIN是语义搜索唯一合理选择，支持词干提取、停用词过滤和语言学处理；pg_trgm+GIN/GiST适用于错别字和模糊匹配；LIKE '%xx%'仅限调试或补救，性能差且索引失效。
tsvector + GIN 索引：真正为语义搜索设计的方案
当你要查“数据库性能优化”，而用户输入的是 performance & database，tsvector 能自动忽略停用词、统一大小写、还原词干（如 optimizing → optimize），再通过 GIN 索引在倒排表里快速定位——这才是语义级匹配。
它不是字符串匹配，是语言学处理后的检索。所以如果你的场景涉及自然语言输入（比如后台内容管理系统的搜索框、文档库关键词查找），tsvector 是唯一合理选择。
- 必须配合
to_tsvector('english', column)显式指定配置，否则默认simple不做词干提取和停用词过滤 -
content_vector TSVECTOR GENERATED ALWAYS AS (...) STORED是最稳写法，避免触发器漏更新或函数重复计算 - 中文必须额外装插件（如
zhparser），原生不支持分词；别指望to_tsvector('chinese', ...)能跑起来 - 索引体积约是原文本的 30–40%，但查询耗时从 1200ms 降到 10–15ms（100 万行实测）
LIKE '%xx%'：只适合极轻量、低频、开发调试用
它不做任何预处理，就是逐字节扫字符串。哪怕字段上有 B-tree 索引，只要开头带 %（如 '%error%'），索引就完全失效——这是硬性限制，不是优化能绕开的。
它的存在意义，仅限于临时查日志字段、补救没建全文索引的老表、或者验证数据是否存在某段固定文本。
-
'error%'可走 B-tree 索引，但'%error'和'%error%'都不行 - 字段长度越长、行数越多，性能断崖式下跌；10 万行以上基本不可用于线上查询
- 无法表达“包含 A 且不含 B”“A 和 B 相距不超过 5 个词”这类逻辑
pg_trgm + GIN/GiST：模糊拼写/错别字/中英文混输的折中解
当你需要查 'postgessql'（少了个 r）也能命中 PostgreSQL，或者用户搜 '微信支付' 但数据库存的是 '微信 支付'（中间有空格），pg_trgm 就派上用场了。它把字符串切成三元组（trigram），靠相似度打分匹配。
但它不是语义搜索：不会理解“run”和“running”是一回事，也不懂“database”和“DB”是否等价。
- 启用前必须
CREATE EXTENSION pg_trgm，否则GIN索引会报错“operator does not exist” -
USING gin(column gin_trgm_ops)和USING gist(column gist_trgm_ops)效果不同：GIN 更快但写入略重；GiST 支持%查询外的相似度排序 -
SELECT * FROM t WHERE col % 'postgessql'这种写法依赖pg_trgm的相似度阈值（默认 0.3），太低易误召，太高漏结果 - 对纯英文短词（如
'api'）效果差：三元组太少，区分度低
选哪个？看你的 query pattern 和数据特征
没有银弹。如果用户搜的是完整单词、带逻辑关系（“Java 并发”但不要 “Spring”）、且你能控制分词语言，tsvector 是首选。如果用户常打错、粘连、缺字，或者字段里塞了大量非结构化短文本（如标签、用户名、商品标题），pg_trgm 更实在。而 LIKE '%...%' 应该被当成最后手段，上线前务必 grep 掉。
最容易被忽略的一点：三者不能混用索引。你建了 GIN on tsvector，再对同一列加 pg_trgm 索引，不仅空间翻倍，查询计划还可能选错索引——PostgreSQL 不会自动判断“这次该用语义还是三元组”。得靠 SET enable_seqscan = off 测试，或用 EXPLAIN (ANALYZE, BUFFERS) 看实际走哪条路。
