引言：為什么不用LIKE？

當我們需要在文章、帖子或產品描述中搜索關鍵詞時，第一個蹦進腦海的可能是SQL的LIKE或ILIKE操作符：

SELECT * FROM posts WHERE body LIKE '%postgres%';

這種方式簡單但問題很多：

1. 性能極差：%postgres%這種前導通配符無法利用索引，會導致全表掃描。

2. 不夠智能：它只能進行嚴格的字符匹配。搜索"run"，不會找到"running"或"ran"。

3. 沒有相關性排序：它只能告訴你“有”或“沒有”，無法告訴你哪條結果更相關。

而PostgreSQL內置的全文搜索（Full-Text Search, FTS） 就是為了解決這些問題而生的。

一、核心概念：文檔、向量與查詢

PostgreSQL的FTS將搜索過程抽象為三步：

1. 文檔（Document）：待搜索的文本單元。可以是一篇文章、一條評論，或者由多個字段組合而成的文本（如 title || ' ' || body）。

2. 向量（tsvector）：對文檔進行處理后的產物。它：

   • 解析和分詞：將文本拆分成一個個獨立的 token（詞位）。

   • 標準化：轉換為小寫。

   • 去除停用詞：移除a, the, is等常見但無搜索意義的詞。

   • 提取詞干：將單詞變為其詞根形式（如 running -> run）。

   • 最終存儲的是(詞位, 位置)形式的列表。

3. 查詢（tsquery）：代表用戶要搜索的內容。它也可以進行詞干提取，并支持邏輯操作符（& 與, | 或, ! 非）。

搜索的本質，就是判斷 @@ 操作符兩邊的 tsvector 和 tsquery 是否匹配。

二、逐行詳解示例SQL

拆解以下SQL語句：

SELECT title, body
FROM posts
WHERE to_tsvector('english', body) @@ to_tsquery('english', 'postgres & optimization');

• to_tsvector('english', body)

  • 功能：生成一個 tsvector。

  • 參數1：'english'：這是一個文本搜索配置（Text Search Configuration）。它決定了使用哪種語言的規則進行分詞、停用詞處理和詞干提取。PostgreSQL支持多種語言（如simple, english, spanish, russian等）。配置的選擇直接影響搜索結果。

  • 參數2：body：需要被處理的文本字段。

  • 結果示例：假設body字段內容是 "PostgreSQL provides powerful optimization tools."，經過處理后會變成： 'power':5 'optim':6 'postgresql':1 'provid':2 'tool':7。可以看到，provides變成了provid（詞干提取），the被移除（停用詞）。

• to_tsquery('english', 'postgres & optimization')

  • 功能：生成一個 tsquery。

  • 參數1：'english'：同樣需要指定配置，確保查詢詞和處理文檔時使用相同的規則（例如，optimization也會被提取詞干為optim）。

  • 參數2：'postgres & optimization'：查詢字符串。&表示同時包含這兩個詞。

  • 結果：一個代表包含詞干 'postgres' 且 包含詞干 'optim'的查詢對象。

• @@ 操作符

  • 功能：布爾匹配操作符。如果左邊生成的 tsvector 匹配右邊生成的 tsquery，則返回true，該行記錄就會被選中。

三、超越基礎：排名與高亮

僅僅找到匹配的文檔還不夠，我們通常需要最好的結果排在前面。

1. 相關性排名（Ranking）： 使用ts_rank函數。

   sql

   SELECT title, body,
          ts_rank(to_tsvector('english', body), 
                  to_tsquery('english', 'postgres & optimization')) AS rank
   FROM posts
   WHERE to_tsvector('english', body) @@ to_tsquery('english', 'postgres & optimization')
   ORDER BY rank DESC;

   ts_rank會根據詞位出現的頻率、位置等因素計算一個相關性分數，然后通過ORDER BY rank DESC將最相關的結果排在頂部。

2. 結果高亮（Highlighting）： 使用ts_headline函數。

   sql

   SELECT title,
          ts_headline('english', body, 
                      to_tsquery('english', 'postgres & optimization')) AS headline
   FROM posts
   WHERE ...;

   ts_headline會在結果中環繞匹配到的詞加上諸如<b>...</b>這樣的HTML標簽，讓用戶在上下文中一眼就看到為什么這條結果被匹配上了，體驗堪比專業搜索引擎。

四、性能優化：GiST/GIN 索引

在WHERE子句中使用函數調用（如to_tsvector(...)）通常會導致無法使用索引。為了讓全文搜索飛起來，必須創建專門的索引。

首選GIN索引，它專為這種“多值列”（一個tsvector里包含很多個詞位）的查詢而優化。

-- 1. 創建一個生成的tsvector列（推薦，易于管理和索引）
ALTER TABLE posts
ADD COLUMN body_tsvector tsvector
GENERATED ALWAYS AS (to_tsvector('english', COALESCE(body, ''))) STORED;
-- 2. 在生成的列上創建GIN索引
CREATE INDEX idx_posts_body_fts ON posts USING GIN(body_tsvector);
-- 3. 查詢語句變得更簡單高效
SELECT title, body
FROM posts
WHERE body_tsvector @@ to_tsquery('english', 'postgres & optimization');

五、與Elasticsearch的比較

結論：如何選擇？

• 使用PostgreSQL FTS：如果你的搜索需求是應用內的、非核心的（如博客搜索、后臺管理搜索），并且你希望保持技術棧簡單、保證數據一致性。

• 使用Elasticsearch：如果你的業務核心是搜索（如電商平臺、新聞網站），需要處理海量數據、復雜的搜索邏輯和高吞吐量。

總結

PostgreSQL的全文搜索是一個被嚴重低估的“隱藏寶石”。它提供了一個在** simplicity（簡單性）** 和 power（功能） 之間絕佳平衡的解決方案。對于許多不需要Elasticsearch這種“重武器”的應用場景來說，它完全足夠且是更優雅的選擇。

通過本文的介紹，希望你能在你的下一個項目中輕松上手這項強大功能！

討論點：

1. 大家在項目中是用PG的全文搜索還是ES？為什么做出這個選擇？

2. 在處理中文全文搜索時，有什么好的配置或分詞方案推薦嗎？（這是一個常見痛點，可以引出zhparser等擴展的討論）