ES和MySQL面對大資料查詢，誰才是效能之王？

這是一個或許對你有用的社群

一對一交流/面試小冊/簡歷最佳化/求職解惑，歡迎加入「芋道快速開發平臺」知識星球。下面是星球提供的部分資料：

《專案實戰（影片）》：從書中學，往事上“練”

《網際網路高頻面試題》：面朝簡歷學習，春暖花開

《架構 x 系統設計》：摧枯拉朽，掌控面試高頻場景題

《精進 Java 學習指南》：系統學習，網際網路主流技術棧

《必讀 Java 原始碼專欄》：知其然，知其所以然

這是一個或許對你有用的開源專案

國產 Star 破 10w+ 的開源專案，前端包括管理後臺 + 微信小程式，後端支援單體和微服務架構。

功能涵蓋 RBAC 許可權、SaaS 多租戶、資料許可權、商城、支付、工作流、大屏報表、微信公眾號、ERP、CRM、AI 大模型等等功能：

Boot 多模組架構：https://gitee.com/zhijiantianya/ruoyi-vue-pro

Cloud 微服務架構：https://gitee.com/zhijiantianya/yudao-cloud

影片教程：https://doc.iocoder.cn

【國內首批】支援 JDK 17/21 + SpringBoot 3.3、JDK 8/11 + Spring Boot 2.7 雙版本

來源：blog.csdn.net/ezreal_pan

/article/details/144292783

在進行資料查詢效能測試的過程中，我的同事么加明對 ES（Elasticsearch）和 MySQL 進行了相對較大資料量的測試，並整理了相關結果。在得到其授權的情況下，我將此對比案例分享給大家，在此再次向么加明表示感謝。

一、結論

透過對es和mysql相對較大資料量的測試，得出結果：在Mysql查詢使用到合適的索引的條件下，透過mysql得到相應結果的速度要明顯優於Es。

基於 Spring Boot + MyBatis Plus + Vue & Element 實現的後臺管理系統 + 使用者小程式，支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能

專案地址：https://github.com/YunaiV/ruoyi-vue-pro

影片教程：https://doc.iocoder.cn/video/

二、透過es實現

Es 文件資料模型：


type Content struct {

    ContentId      int64  `json:
"id"
`              
// 內容id
    PermissionType 
int
    `json:
"permission_type"
` 
// 許可權型別 0:公開，1:僅自己可見，2:部分可見，3:不給誰看
    TopicId        
int
    `json:
"topic_id"
`        
// 話題id
    AllowUser      []User `json:
"allow_user"
`      
// 允許的使用者
    BlockUser      []User `json:
"block_user"
`      
// 遮蔽的使用者
}
type User struct {

    Id int64 `json:
"id"
` 
// 使用者id
}

測試資料量及條件

測試 ES 資料量為 2000 萬的作品數，5000 的使用者量（此使用者量與實際情況有出入，理論上應有至少 20 萬的使用者量）。

當設定給部分人可見時，AllowUser 內有 30 個元素；同樣，當設定不給誰看時，BlockUser 內也是有 30 個元素。所以對應的總資料量在 3 億條左右。

查詢條件如下：

1、單獨查詢公開可見資料：查詢時間在275毫秒左右

2、單獨查詢部分可見資料：耗時70毫秒左右

3、單獨查詢部分不可見資料：耗時255毫秒左右

4、合併三次查詢未一次查詢就得到結果的話：耗時428毫秒左右

綜上所述採用 Es最快的響應時間為並行執行每次查詢，耗時在300毫秒以內。

基於 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的後臺管理系統 + 使用者小程式，支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能

專案地址：https://github.com/YunaiV/yudao-cloud

影片教程：https://doc.iocoder.cn/video/

三、透過mysql實現

Mysql 表結構如下：

CREATETABLE`content_permission_1`
 (
`id`intunsignedNOTNULL
 AUTO_INCREMENT 
COMMENT'主鍵自增'
,
`content_id`intNOTNULLDEFAULT'0'COMMENT'內容id'
,
`permission_type`tinyintNOTNULLDEFAULT'0'COMMENT'許可權型別 0:公開，1:僅自己可見，2:部分可見，3:不給誰看 '
,
`topic_id`intNOTNULLDEFAULT'0'COMMENT'話題id'
,
`user_id`intNOTNULLDEFAULT'0'COMMENT'許可權針對的使用者id'
,

  PRIMARY 
KEY
 (
`id`
) 
USING
 BTREE,
KEY`idx_content_id`
 (
`content_id`
) 
USING
 BTREE,
KEY`idx_user_id_content_id`
 (
`user_id`
,
`content_id`
)

) 
ENGINE
=
InnoDB
 AUTO_INCREMENT=
1DEFAULTCHARSET
=utf8mb4 
COMMENT
=

'內容許可權表（可見設定）'

測試條件及資料量

測試 MySQL 資料量為 1000 萬的作品資料，總共 1.5 億許可權相關資料。

查詢條件如下：

1、查詢公開資料：耗時21毫秒左右；使用到的索引為 idx_content_id

2、查詢部分人可見：耗時48毫秒左右；使用到的索引為 idx_user_id_content_id

3、查詢部分人不可見：耗時13毫秒左右；使用到的索引為 idx_content_id

綜上所述採用 mysql最快的響應時間為並行執行每次查詢，耗時在50毫秒以內

總結

1.mysql建立合適的索引，避免回表的情況下，其查詢效能還是非常優異的。

2.對於 ES 的測試結果，其實並不令人意外。不過，對於 ES 在字典中查詢對應 keyword 的具體方式，我充滿了好奇。目前我在思考它是否基於二分法進行查詢呢？

畢竟在面對龐大的資料量時，如果採用二分法，可能會在一定程度上影響查詢速度。遺憾的是，目前我還沒有找到關於 ES 底層查詢原理的詳細資料，所以這僅僅是我的一種猜測罷了。倘若讓我來編寫這樣一個程式，在沒有更多資訊的情況下，二分法或許是我首先能想到的一種實現方式。

但我深知，ES 作為一款成熟的搜尋引擎，其查詢原理必定更加複雜和高效，肯定不僅僅侷限於簡單的二分法。我期待著深入瞭解 ES 的底層查詢機制，以便更好地理解和應用它在實際專案中的強大功能。這個問題有時間再做深入研究。

透過這次對比測試，我們可以看出在特定的查詢場景下，MySQL 在效能上有著明顯的優勢。然而，ES 也有其獨特的應用場景，如全文搜尋等。在實際應用中，我們需要根據具體的需求來選擇合適的資料庫技術，以達到最佳的效能和效果。

歡迎加入我的知識星球，全面提升技術能力。

加入方式，“長按”或“掃描”下方二維碼噢：