想要在ES中使用*或者?作為萬用字元進行模糊匹配？
看這篇就對了～

本文為轉發！！！

轉自：https://blog.csdn.net/dm_vincent/article/details/42024799

wildcard查詢和prefix查詢類似，也是一個基於詞條的低級別查詢。但是它能夠讓你指定一個模式(Pattern)，而不是一個字首(Prefix)。它使用標準的shell萬用字元：?用來匹配任意字元，*用來匹配零個或者多個字元。

以下查詢能夠匹配包含W1F 7HW和W2F 8HW的文件：

GET /my_index/address/_search
{
    "query": {
        "wildcard": {
            "postcode": "W?F*HW" 
        }
    }
}
 

假設現在你想匹配在W地域(Area)的所有郵政編碼。使用字首匹配時，以WC開頭的郵政編碼也會被匹配，在使用萬用字元查詢時也會遇到類似的問題。我們只想匹配以W開頭，緊跟著數字的郵政編碼。使用regexp查詢能夠讓你寫下更復雜的模式：

GET /my_index/address/_search
{
    "query": {
        "regexp": {
            "postcode": "W[0-9].+" 
        }
    }
}

這個正則表示式的規定了詞條需要以W開頭，緊跟著一個0到9的數字，然後是一個或者多個其它字元。

wildcard和regexp查詢的工作方式和prefix查詢完全一樣。它們也需要遍歷倒排索引中的詞條列表來找到所有的匹配詞條，然後逐個詞條地收集對應的文件ID。它們和prefix查詢的唯一區別在於它們能夠支援更加複雜的模式。

這也意味著使用它們存在相同的風險。對一個含有很多不同詞條的欄位執行這類查詢是非常消耗資源的。避免使用一個以萬用字元開頭的模式(比如，*foo或者正則表示式: .*foo)。

儘管對於字首匹配，可以在索引期間準備你的資料讓它更加高效，萬用字元和正則表示式匹配只能在查詢期間被完成。雖然使用場景有限，但是這些查詢也有它們的用武之地。

注意

prefix，wildcard以及regexp查詢基於詞條進行操作。如果你在一個analyzed欄位上使用了它們，它們會檢查欄位中的每個詞條，而不是整個欄位。

比如，假設我們的title欄位中含有"Quick brown fox"，它會產生詞條quick，brown和fox。

這個查詢能夠匹配：

{ "regexp": { "title": "br.*" }}

而不會匹配：

{ "regexp": { "title": "Qu.*" }} 
{ "regexp": { "title": "quick br*" }}