本系列第 1 篇。先搞清楚LIKE %keyword%到底差在哪全文搜索又解决了什么问题。LIKE 的三宗罪假设有一张文章表想搜标题/正文里含某个词的记录。很多人第一反应SELECT*FROMarticlesWHEREcontentLIKE%数据库%;看着能用但生产上有三个致命问题1. 无法走索引前导通配符LIKE %xxx%开头是%普通 B-Tree 索引用不上只能全表扫描。几十万行就开始慢上千万行直接卡死。2. 不理解“词”只会字符匹配LIKE %run%会匹配到running、brunch——它不懂英文词干也不懂中文分词。搜apple匹配不到apples除非再写规则搜“数据库”匹配不到“数据 库”。3. 没有相关性排序LIKE 只能告诉你“匹配/不匹配”不能告诉你“哪条更相关”。而搜索的核心恰恰是把最相关的排前面。全文搜索怎么解决PostgreSQL 全文搜索FTS做了三件 LIKE 做不到的事能力LIKE全文搜索走专用索引GIN❌✅ 快分词 / 词干归一化❌✅run/running 归一相关性排名❌✅ts_rank关键词高亮❌✅ts_headline布尔/短语查询与或非勉强✅tsquery核心思路把文档预处理成一堆**归一化的词lexeme**存进tsvector再用tsquery表达查询条件两者用匹配并用 GIN 索引加速。一个直观对比-- LIKE字符匹配全表扫描SELECT*FROMarticlesWHEREcontentLIKE%running%;-- FTS词匹配run/running/ran 都能命中可走 GIN 索引SELECT*FROMarticlesWHEREto_tsvector(english,content) to_tsquery(english,running);什么时候还是用 LIKE精确前缀匹配LIKE abc%能走索引。数据量很小或只是偶尔模糊查。需要匹配任意子串片段如搜商品编号中间几位FTS 反而不合适。记住LIKE 是字符匹配FTS 是语义/词匹配。搜“文章内容、评论、描述”这类自然语言文本用 FTS。下一篇核心概念 tsvector / tsquery / 分词配置