本文的測試是基於740w條測試資料進行的，只討論like模糊查詢的優化方案。其他SQL優化可參考：
SQL優化的幾種方式

查詢開頭是“今天不開心”的聊天記錄，是可以走索引的。

select * from message_1 where content like "今天不開心%”;

查詢包含“今天不開心”的聊天記錄，是不能走索引的。

select * from message_1 where content like "%今天不開心%";

咱們主要優化的是第二種情況，我本人測試查詢耗時是在9秒。

優化方案

對於查詢包含某個關鍵詞的需求，從業務上來說應儘量避免這種不合理的需求。

但是實際使用中，總有些類似需求避免不掉模糊查詢，就可以採取下列優化方式。

• 稍微優化

select * from message_1 where instr(content, "今天不開心") > 0;

select  * from message_1 where locate("今天不開心", content) > 0;

這個方法優化效果有限，這兩種方法耗時相差不多，比不優化要快上2~3秒。

我還測試了一些其他的一些情況，這種優化方式，在某些情況下會比優化前還要慢，由此可見這種方式是有坑的。

比如優化前：

select content from message_1 where content like "%今天不開心%";

優化後：

select content from message_1 where instr(content, "今天不開心") > 0;

select content from message_1 where locate(
 
"今天不開心", content) > 0;

這種情況，優化後比不優化要慢上2秒左右。。。。

• 大幅度優化

select * from message_1 where content in 
(select content from message_1 where content like "%今天不開心%");

這種方法，能將查詢優化至3秒左右，優化效果已經很明顯。

優化原理：用索引全掃描取代表的全掃描。因為索引全掃描的代價是全表掃描的1/N （即索引塊數與資料塊數的比例），表資料越多，優化效果越明顯。

優化後的sql語句，根據索引再回表的代價要看符合條件的記錄數多少：如果in子查詢返回的記錄數很少，那麼優化的效果就相當於效率提高了N倍；如果in子查詢返回的記錄數較多，兩種SQL的效能區別就不是很明顯了。

根本優化
使用ClickHouse 或者 Elasticsearch 同步資料庫。

這兩種方式可以從根本上解決模糊查詢的高延時，但是需要引入一套新的系統，代價還是不小的。

二者的對比可參考：
Elasticsearch和Clickhouse基本查詢對比
ClickHouse 與es比較
————————————————
版權宣告：本文為CSDN博主「終成一個大象」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/Martin_chen2/article/details/121407417