在對某電商項目進行接口性能壓測時，發現 /product/search 接口響應緩慢，存在明顯性能瓶頸。通過慢查詢日志排查和 SQL 優化，最終實現了接口響應速度的顯著提升。本文完整還原此次優化過程，特別強調操作步驟和問題分析過程，為后續類似問題提供可復用參考。
一、問題背景
接口地址：
GET /product/search?keyword=手機&pageNum=1&pageSize=10
該接口支持關鍵詞模糊搜索和分頁查詢，是產品列表頁的重要入口。
二、JMeter 接口壓測
使用 JMeter 進行 50 和 100 并發下的性能測試，結果如下：
| 并發數 | 樣本數 | 平均響應時間(ms) | 最小值 | 最大值 | 標準差 | 吞吐量(req/s) |
|---|---|---|---|---|---|---|
| 50 | 50 | 5869 | 2364 | 8465 | 1939 | 5.3 |
| 100 | 100 | 10791 | 2364 | 21543 | 5727 | 6.71 |
接口平均響應時間達到 5~10 秒，明顯偏高，響應抖動也較嚴重。
三、開啟 MySQL 慢查詢日志
為定位 SQL 性能瓶頸，需先開啟 MySQL 的慢查詢日志。步驟如下：
1. 登錄數據庫
、
mysql -uroot -p
2. 臨時開啟慢查詢日志（即時生效）
SET GLOBAL slow_query_log = 1;
SET GLOBAL slow_query_log_file = '/var/lib/mysql/mysql-slow.log';
SET GLOBAL long_query_time = 1; -- 超過1秒即記錄為慢查詢
SET GLOBAL log_queries_not_using_indexes = 1;
3. 查看設置是否生效
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';
4. 永久配置（推薦）
編輯配置文件 /etc/my.cnf：
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/lib/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1
重啟 MySQL 生效：
docker restart mysql
四、慢 SQL 日志分析
壓測執行期間，慢查詢日志出現以下記錄：
tail -n 50 /var/lib/mysql/mysql-slow.log
Query_time: 2.606188 Rows_examined: 118788
SELECT id, name, price, ...
FROM pms_product
WHERE delete_status = 0AND publish_status = 1AND name LIKE '%手機%'
LIMIT 10;
分析結果：
- LIKE ‘%手機%’ 會導致 無法使用索引；
- Rows_examined 超過 11 萬，全表掃描嚴重拖慢性能；
- 查詢時間達 2.606188 秒，符合慢 SQL 記錄門檻；
- 實際僅返回幾行數據，說明檢索效率極低。
五、SQL 優化策略
? 優化 1：添加聯合索引（過濾條件優化）
CREATE INDEX idx_publish_delete ON pms_product (publish_status, delete_status);
目標：加速前置過濾條件，縮小掃描范圍。
? 優化 2：替換模糊搜索模式（條件允許時）
將：
name LIKE '%手機%'
替換為前綴匹配：
name LIKE '手機%'
并添加索引：
CREATE INDEX idx_name ON pms_product(name);
說明：前綴匹配可命中索引，大幅提升查詢性能。
? 優化 3：MySQL FULLTEXT 索引（英文關鍵詞可用）
ALTER TABLE pms_product ADD FULLTEXT(name);
使用：
MATCH(name) AGAINST('手機');
注意：MySQL 原生不支持中文分詞，適用于英文搜索場景。
? 優化 4：引入 Elasticsearch（推薦）
對于中文模糊搜索，應優先考慮引入 Elasticsearch：
- 支持中文分詞（如 IK Analyzer）；
- 查詢速度快，靈活性強；
- 支持高亮、相關度排序、糾錯、自動補全等高級搜索功能。
七、總結
🎯 優化流程回顧：
- 壓測工具發現接口響應慢
- 開啟慢查詢日志，定位 SQL 問題
- 分析執行計劃，確認未命中索引、全表掃描
- 針對性優化索引和搜索邏輯
- 回歸驗證優化效果
📌 經驗建議：
| 建議 | 說明 |
|---|---|
| 開啟慢查詢日志 | 持續監控系統中潛在瓶頸 SQL |
| 適當控制模糊查詢的使用 | %關鍵詞% 頻繁使用時應考慮全文檢索方案 |
| 數據量較大時應提前評估查詢方式 | 多字段過濾、分頁查詢要設計好索引策略 |
| 中文搜索建議引入搜索引擎 | 如 Elasticsearch，提升性能和用戶體驗 |
)
