每天早上七點三十，準時推送干貨

一、介紹

在這篇文章中 利用springboot+elasticSearch，實現數據高效搜索，實戰開發，我們介紹了 SpringBoot 整合 ElasticSearch 開發，以及一些基礎的 CRUD。

我們都知道，ElasticSearch 真正的強大的地方在于面對海量數據，依然能實現高效搜索，既然如此，本篇就以此為基礎，將數據庫查詢與 Elasticsearch 進行查詢性能對比，看看誰的查詢速度更快！

廢話不多說，先新建一張學生表student，字段內容如下：

為了貼近海量數據這一特性，小編特意在學生表student中造了 1千萬條數據，本來是想造 1個億的，但是造數據實在太耗時了，挑戰比較大，當一張表的數據量到達1千萬時，查詢性能查詢已經很明顯了，所以造 1 個億的夢想暫且擱置！

下面，我們就一起來看看兩者之間的性能差別！

• 數據庫版本：mysql-8.0.18

• ElasticSearch 版本：6.1.0

二、數據庫性能測試

可能有些同學很好奇，當一張表的數據量到達 1千萬之后，單表的增刪改查是否如往常一樣高效？

今天我們就一起來實戰觀察，先直接利用數據庫工具來測試一下！

2.1、CRUD測試

2.1.1、查詢測試

• 通過主鍵id，搜索信息

• 通過非主鍵id，搜索姓名張三1的信息

可以很清晰的看到，搜索花費時間6s，可能有些同學不信，一條查詢結果無法令人信服，那我換別的名稱測試一下！

從數據上，可以很清晰的看到，如果通過主鍵ID查詢會非常快，但是如果通過非主鍵字段查詢比較慢，一個單表查詢平均耗時 6s！

2.1.2、新增測試

• 插入一條數據，姓名趙云

從數據上看，插入耗時比較短！

2.1.3、修改測試

• 通過主鍵id，修改信息

• 通過非主鍵，修改信息

可以很清晰的看到，如果通過主鍵ID來修改會非常快，如果是通過非主鍵修改會非常慢！

2.4、刪除測試

• 通過主鍵id，刪除數據

• 通過非主鍵字段，刪除數據

從數據上可以看出，當通過主鍵ID進行刪除非常快，但通過非主鍵刪除超級慢！

總結：從curd測試結果來看，一張單表數據超過1千萬時，增刪改查效率會逐漸變慢！一般情況下，我們的接口請求都會設置超時時間，例如，頻繁的查詢功能都需要耗時6秒，接口請求基本百分之百的報超時錯誤！

2.2、為字段添加索引

面對這種情況應該如何應對呢？首先我們試試給關鍵字段name添加索引！

再來，搜索姓名張三1的信息，結果如下：

搜索姓名張三88的信息，耗時結果如下：

搜索姓名張三8888的信息，耗時結果如下：

從結果上看，整體耗時：0.003s！

從這里，我們可以很清晰的看出：創建索引，可以大大提高表的性能！

這也說明了，為什么我們在創建表的時候，明確規定，對于關鍵的查詢字段，一定要加索引的原則！

當然創建過多的索引也有缺點！

• 第一：創建索引和維護索引比較耗費時間，當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度，同時隨著數據量的增加，維護索引的耗時也會更長。

• 第二：索引需要占用物理空間，隨著表數據不斷的增大，索引需要空間也會變大。

因此，在實際開發中，還需要根據具體的業務場景來確定哪些字段需要創建索引！

三、Elasticsearch 性能測試

說完數據庫，我們接著來看看 Elasticsearch 的表現如何！

為了跟數據庫中的數據量保持一致，小編也花了一些時間，將數據庫中學生表的數據全部遷移到了 Elasticsearch 中！

我們可以通過Elasticsearch-head插件登錄 Elasticsearch 的 Web 管理頁面查看結果！

3.1、CRUD測試

3.1.1、查詢測試，默認每頁最多查詢10條

從數據結果上看，耗時基本在0.5s之內，可以說吊打從數據庫直接查詢數據的耗時！

3.1.2、新增測試

插入一條數據，耗時0.2s左右，結果如下：

批量插入，耗時在0.1s左右，結果如下：

3.1.3、修改測試

修改時，只需要傳入ID即可，Elasticsearch 會根據ID作為索引，判斷是否存在，如果存在，就進行更新，如果不存在，就將其插入！

修改不存在的ID，進行請求！

查詢王小賤信息！

3.1.4、刪除測試

傳入指定ID，即可刪除信息！

四、總結

本文內容，主要圍繞數據庫與 elasticSearch，在大數據查詢方面，性能的實測比較！

總的來看，elasticSearch 在大數據查詢方面要遠優于從數據庫中直接查詢，因此，如果所在項目的數據庫容量已經超過千萬，建議將數據遷移到 elasticSearch 上進行全文搜索，或者合理的使用索引，性能會明顯翻倍！

本文可能也有遺漏的地方，歡迎網友點評、吐槽！

由于公號不能直接點擊外鏈，關注「Java極客技術」，回復「202007018」，即可獲取 Springboot 整合 elasticSearch 源碼項目~

最后說兩句（求關注）

最近大家應該發現微信公眾號信息流改版了吧，再也不是按照時間順序展示了。這就對阿粉這樣的堅持的原創小號主，可以說非常打擊，閱讀量直線下降，正反饋持續減弱。

所以看完文章，哥哥姐姐們給阿粉來個在看吧，讓阿粉擁有更加大的動力，寫出更好的文章，拒絕白嫖，來點正反饋唄~。

如果想在第一時間收到阿粉的文章，不被公號的信息流影響，那么可以給Java極客技術設為一個星標。

最后感謝各位的閱讀，才疏學淺，難免存在紕漏，如果你發現錯誤的地方，由于本號沒有留言功能，還請你在后臺留言指出，我對其加以修改。

最后謝謝大家支持~

最最后，重要的事再說一篇~

快來關注我呀~
快來關注我呀~
快來關注我呀~

< END >

如果大家喜歡我們的文章，歡迎大家轉發，點擊在看讓更多的人看到。也歡迎大家熱愛技術和學習的朋友加入的我們的知識星球當中，我們共同成長，進步。

總結

以上是生活随笔為你收集整理的数据库与elasticSearch，大数据查询性能PK的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。