1. 项目背景与问题定位
去年接手的一个电商后台系统遇到了严重的查询性能问题。每当用户在搜索框输入模糊关键词（比如"男士运动鞋 2023新款"）时，MySQL的LIKE查询响应时间经常超过5秒，高峰期直接导致数据库连接池耗尽。通过EXPLAIN分析发现，即便在product_name字段加了普通索引，LIKE '%关键词%'这类查询还是走了全表扫描——这是典型的模糊查询性能瓶颈。
我们测试过几种常规优化方案：
- 使用FULLTEXT索引：对中文分词支持差，且无法处理"2023新款"这类混合文本
- 增加Elasticsearch同步：但需要重构整个数据流，工期至少两个月
- 改用专门的搜索引擎：学习成本和维护代价太高
最终我们选择了一个折中方案：在现有架构基础上，用C++开发轻量级ElasticClient组件，将模糊查询请求智能路由到Elasticsearch，而精确查询继续走MySQL。实测将平均响应时间从4.7秒降到了48毫秒，相当于提升了近100倍。
2. 技术方案设计
2.1 整体架构设计
系统采用双写模式保持数据一致性：
code复制MySQL -> Binlog监听 -> C++ ElasticClient -> Elasticsearch
↘ 应用层直接双写 ↗
关键设计点：
- 数据同步策略：优先使用MySQL binlog保证基础数据一致性，应用层双写作为补偿机制
- 查询路由规则：
- 包含
%通配符的LIKE查询 → 转发到Elasticsearch - 等值查询（WHERE id=123）→ 继续走MySQL
- 包含
- 降级方案：ES集群不可用时自动切换回MySQL查询
2.2 ElasticClient核心实现
用C++17实现的高性能客户端主要包含以下模块：
cpp复制class ElasticClient {
public:
// 构造时加载配置文件
ElasticClient(const std::string& config_path);
// 批量写入文档
bool BulkInsert(const std::vector<Product>& products);
// 模糊查询接口
std::vector<Product> FuzzySearch(const std::string& keyword);
// 健康检查
bool HealthCheck() const;
private:
httplib::Client http_client_; // 基于libcurl的HTTP客户端
std::string index_name_; // ES索引名
std::mutex mutex_; // 线程安全锁
};
性能优化关键点：
- 使用连接池复用HTTP连接
- 批量写入时开启
refresh_interval=-1避免频繁刷新 - 查询时指定
_source_filtering减少网络传输
3. 关键实现细节
3.1 数据同步机制
通过C++监听MySQL binlog的典型代码结构：
cpp复制void BinlogListener::Start() {
mysql_binlog_connect(&conn);
while (running_) {
BinlogEvent event = mysql_binlog_wait_for_event(&conn);
if (event.type == WRITE_ROWS_EVENT) {
Product product = ParseProduct(event.data);
elastic_client_.BulkInsert({product});
}
// 处理UPDATE/DELETE事件...
}
}
注意：需要特别处理DDL变更事件，建议在ES端通过别名机制实现索引无缝切换
3.2 查询路由实现
查询路由的核心逻辑：
cpp复制QueryResult QueryRouter::Execute(const std::string& sql) {
if (IsFuzzyQuery(sql)) { // 判断是否包含LIKE '%...%'
std::string keyword = ExtractKeyword(sql);
auto results = elastic_client_.FuzzySearch(keyword);
return ConvertToMySQLResult(results);
} else {
return mysql_conn_.Execute(sql);
}
}
模糊查询识别算法要点：
- 使用正则表达式匹配
LIKE '%[^%]+%'模式 - 排除
LIKE 'prefix%'（这类查询可以用MySQL索引） - 处理转义字符如
LIKE '%100%%'匹配"100%"
4. 性能优化实战
4.1 Elasticsearch索引设计
优化后的商品索引mapping：
json复制{
"settings": {
"analysis": {
"analyzer": {
"product_analyzer": {
"type": "custom",
"tokenizer": "ik_max_word",
"filter": ["lowercase"]
}
}
},
"refresh_interval": "30s" // 降低刷新频率
},
"mappings": {
"properties": {
"product_name": {
"type": "text",
"analyzer": "product_analyzer",
"fields": {
"keyword": {"type": "keyword"}
}
},
"price": {"type": "double"}
}
}
}
4.2 查询DSL优化
原始模糊查询：
json复制{
"query": {
"wildcard": {
"product_name": "*运动鞋*"
}
}
}
优化后的组合查询：
json复制{
"query": {
"bool": {
"should": [
{"match": {"product_name": "运动鞋"}},
{"match_phrase": {"product_name": "2023新款"}}
],
"minimum_should_match": 1
}
},
"size": 50,
"_source": ["id", "product_name", "price"] // 按需返回字段
}
性能对比：
| 查询类型 | 平均耗时(ms) | QPS |
|---|---|---|
| MySQL LIKE | 4700 | 2 |
| ES Wildcard | 120 | 80 |
| ES 组合查询 | 48 | 200 |
5. 踩坑经验与解决方案
5.1 中文分词问题
初期直接使用standard analyzer导致中文被拆分成单字：
code复制"男士运动鞋" → ["男", "士", "运", "动", "鞋"]
解决方案：
- 安装IK分词插件
- 配置ik_max_word分词器
- 重建索引时指定新的analyzer
5.2 数据一致性问题
曾出现MySQL删除记录后ES仍可查询到的case，解决方案：
cpp复制void BinlogListener::HandleDeleteEvent(const BinlogEvent& event) {
std::string product_id = ParseProductId(event.data);
elastic_client_.DeleteById(product_id);
// 双写补偿机制
if (!elastic_client_.IsSuccess()) {
retry_queue_.Push(product_id);
}
}
5.3 内存泄漏排查
Valgrind检测到的典型问题：
- libcurl连接未正确关闭 → 使用RAII包装器
- JSON解析时内存分配异常 → 改用simdjson替代rapidjson
- 线程池任务队列积压 → 增加最大队列大小监控
6. 部署与监控方案
6.1 容器化部署
Dockerfile核心配置：
dockerfile复制FROM ubuntu:20.04
RUN apt-get update && apt-get install -y \
libcurl4-openssl-dev \
libmysqlclient-dev
COPY elasticclient /app/
CMD ["/app/elasticclient", "-c", "/etc/elasticclient.conf"]
6.2 监控指标
通过Prometheus暴露的关键指标：
- es_query_latency_seconds
- mysql_fallback_count
- thread_pool_queue_size
- bulk_insert_duration
Grafana监控看板配置建议：
- 设置QPS变化趋势图
- 添加99分位响应时间告警
- 监控ES集群健康状态
这个方案在保证系统架构最小改动的前提下，用相对低的成本解决了模糊查询的性能瓶颈。实际开发中最大的挑战其实是数据一致性的保障，我们最终通过"binlog监听+双写补偿+定时校对"三重机制来确保可靠性。对于需要快速解决MySQL模糊查询性能问题的团队，这个方案值得参考。