先講結論: 搜尋真的很難, 搜中日韓文又比拉丁語系更難!

此外, 搜尋屬於電腦工程裡面的高階應用, 所以通常大學四年的基礎課程不會專門開這學科, 大多要到研究所裏面, 變成論文研究項目才會有實作經驗.

大部分工程師的全文搜尋(Full Text Search)技能, 多是進了業界之後, 才開始接觸學習. 而且也要你待的公司有深度應用才會精進, 若公司不重視也不投入資源開發的話, 就是得到樓主目前看到的結果: 明明知道文章裡面有這個詞, 卻硬是搜不出來.

一般 Junior 工程師可能只學過 SQL-Based 關聯式資料庫 (RDBMS),
來看一下 RDMBS 做全文檢索, 需要甚麼條件:
在 MySQL 中執行全文檢索搜尋（第 1 部分）

初看很簡單, 就是: 限制只有幾種欄位型別可以做, 然後要定義 Fulltext 索引...等等, 照表操課就可建好 Table, 也可以完成大部分搜尋的工作 (還不是全部條件可以搜); 但當你開始把資料往裡面放, 剛開始沒感覺, 到了資料量累積 數百GB 等級之後, 就會發現一件事情:

全文檢索慢到靠杯!!

又因全文檢索拖慢整個 DB 的效能, 造成全部會用到 DB 的功能都跟著被拖慢,
所以副作用就是:

整個網站慢到靠杯!!

這個災難, 在早期的 Microsoft Sharepoint 2010 產品中發生過, 被全球用戶罵到翻.
如果公司裡面沒有架構師懂搜尋技術的話, 公司就是叫你趕快把它關掉, 免得影響業務!

再來第二個問題, 搜尋類型至少有三種:

• 自然語言全文檢索
• 布林全文檢索
• 擴展查詢

自然語言部份, 如果沒有導入 NLP 分析的話, 光靠 RDBMS 自己是很難做到合乎人性:
在 MySQL 中執行全文檢索搜尋（第 ２ 部分）
在上例中, 他只有搜尋一個詞, 根本還稱不上自然語言, 但結果就已經讓人難以選擇了.

文章是一種非結構性的資料, 把它放進擅長結構性的 RDBMS 裡去處理, 根本是拿錯武器.

為了減輕無謂的負擔, 全文檢索需要有專門處理非結構性資料的搜尋引擎來擔任, 如:
Apache Lucene

許多搜尋應用系統, 如: Solr, Elasticsearch, Azure Cognitive Search, 都是以 Apache Lucene 為基礎, 往上開發出來的搜尋應用系統. 這些搜尋應用系統都已經編寫成 API 的型態, 所以串接到網站上, 只需要透過 API 呼叫, 塞給他正確的語法就可以搜尋, 你不需要再自己寫解析搜尋語意的程式.

但是維護以上這些搜尋應用系統, 又是另一種專門的技能; 如果要把它引進網站內使用, 要不是開發工程師自己要多花時間去負責維護, 要不就是另外聘請專門的人來維護. 所以建構全文檢索功能, 會是網站非常龐大的額外負擔, 除非有相當大的利益回報, 否則一般網站業者不願意投資這些.

在美國, 專職於 Elasticsearch 開發的工程師, 年薪中位數大約 14 萬美金:
https://www.ziprecruiter.com/Salaries/Elasticsearch-Engineer-Salary
Solr 工程師年薪大約是 8 萬美金:
https://www.glassdoor.com/Salaries/solr-developer-salary-SRCH_KO0,14.htm

如果不想自己搞全文檢索, 也可以直接跟 Google Search 串接;
例如台灣流行的 Mobile01 網站, 他的搜尋就是直接交給 Google.

以下是全球最大的資訊技術論壇: Stack Exchange, 內部的系統架構:

它們用三台 192GB RAM 的 Elasticsearch 來做全文檢索, 完整的技術架構說明在此:
https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
它們每天要顯示六千多萬個網頁, 以及一千七百多萬次的 Elasticsearch 搜尋 (2016 年)

ps. Dcard 不算是流量大的論壇網站, 她全球排名還排不進 Top 1000 以內, 全月份的總瀏覽數也才四千萬上下, 在台灣還輸給 ptt.cc (至少人家還有進 Top 1000); 上面 Stackoverflow 論壇 (全球流量排名第 229), 一天的網頁量就超過他一個月:
https://www.similarweb.com/zh-tw/website/dcard.tw/vs/ptt.cc/#overview

搜尋的技術其實很深奧。

早期我在玩論壇時，一開始接觸的是所謂的二分詞的方式。
但這其實也不是最好的方法。因為後來碰到100G級的就直接死掉了。

在當時，其實我了解了幾個困難度。
其一就是SQL資料庫的索引及全文索引。都對非英數來說是非常的不友好。
這也就造成了，早期全文索引當量達一定量時會慢到想罵人。
畢竟就算全英數好了。也只是容許多一點量而已。

其二就是其為了索引量降低。所以只有4個字元以上才會被編入索引內。
這對我們使用中文的人來說，是一個很大的問題

所以我在當時曾經花了3個多月的時間，研究如何利用全文索引並加快速度及容許負載的搜尋量。
是研究出一個都也不太算太好的方式。
畢竟我的方向是用「空間」來換取「時間」的方法。
也就是一種演算的處理技術。

詳情我就不便明說。但大體上主要還是為了不要因為系統因為搜尋而去影響到所有的功能。
所以全文索引相關的欄位。會另外建立一個表來建立處理。
平常不搜尋，則只會生成新的內容索引資料。(當然了，索引資料是經過編碼處理過的，方便全文索引及分數演算)

只有在搜尋的當下才會去使用索引資料。
這樣可以避免在搜尋當下，去影響到其它功能的情況。

其實目前我自已的論壇，就是採用我研發出來的搜尋機制。
不過我剛說了。我是利用了「空間」換取「時間」的方式。
也就是說，我的搜尋方法。會在無形之中，增加約1.5~2.5倍的容量。
而且搜尋速度上的比較。還是比使用 Apache Lucene..等相關搜尋應用慢了一些。
(這是拿100G等級的資料來測試差異)

但其速搜尋的速度還是容許範圍內。