《从 MyBatis-Plus 到 Elasticsearch：一个后端的性能优化踩坑实录》

​

最近接手了一个老项目，单表查询用 MyBatis-Plus 写得飞起，但一到​​多表关联+模糊搜索​​就卡成 PPT。痛定思痛，决定引入 Elasticsearch 优化查询性能，结果踩坑无数……记录下这次​​从 ORM 到搜索引擎​​的升级历程，分享给同样被慢查询折磨的你。

1. 问题定位：MP 的舒适区边界​​

MyBatis-Plus 的 QueryWrapper 在单表操作中确实优雅：

// 条件查询示例（单表）
List users = userService.lambdaQuery()
    .eq(User::getStatus, 1)
    .like(User::getName, "张")
    .list();

但遇到​​跨表 JOIN + 高并发模糊查询​​时，MySQL 直接裂开：

• 大表 LIKE '%关键词%' 导致全表扫描
• 分页 COUNT 计算拖慢响应（即使用了 PageHelper）

​​结论​​：MP 适合 OLTP 简单场景，OLAP 复杂查询得换方案。

---

​​2. 技术选型：ES 还是 ClickHouse？​​

面对海量数据搜索，纠结了两个方案：

方案	优点	缺点
​​Elasticsearch​​	实时搜索快，支持分词高亮	资源占用高，学习曲线陡峭
​​ClickHouse​​	列式存储，聚合分析强	不适合频繁更新/点查

最终选择 ​​ES​​，因为：

1. 业务需求以​​模糊搜索+排序​​为主（如商品名称、用户昵称）
2. 已有 ES 集群，可复用运维资源

---

​​3. 实战：SpringBoot 集成 ES​​

​​(1) 引入依赖​​

    org.springframework.boot
    spring-boot-starter-data-elasticsearch

注意版本匹配（Spring Data ES 和 ES 服务端版本需兼容）。

​​(2) 实体类映射​​

用注解定义 ES 索引结构和分词器：

@Document(indexName = "products", createIndex = false)
public class Product {
    @Id
    private Long id;
    
    @Field(type = FieldType.Text, analyzer = "ik_max_word") // 中文分词
    private String name;
    
    @Field(type = FieldType.Double)
    private Double price;
}

​​(3) 混合查询策略​​

​​写操作​​：双写 MySQL 和 ES（本地事务+消息队列补偿）

@Transactional
public void addProduct(Product product) {
    // 1. 写入 MySQL
    productMapper.insert(product); 
    // 2. 发MQ消息异步写入ES（防止事务失败污染ES）
    rocketMQTemplate.send("es-update-topic", product);
}

​​读操作​​：走 ES 查询，兜底查 MySQL

public Page search(String keyword, int page, int size) {
    NativeSearchQuery query = new NativeSearchQueryBuilder()
        .withQuery(QueryBuilders.matchQuery("name", keyword)) // 分词匹配
        .withPageable(PageRequest.of(page, size))
        .build();
    return elasticsearchRestTemplate.search(query, Product.class);
}

---

​​4. 性能对比​​

压测结果（100万数据，并发 200）：

查询类型	MySQL + MP	ES
单字段精确查询	120ms	15ms（↑8倍）
多字段模糊查询	2800ms（全表扫）	50ms（↑56倍）
排序分页	900ms	30ms（↑30倍）

代价：ES 索引延迟约 1s（近实时），存储占用是 MySQL 的 2 倍。

---

​​5. 深度踩坑​​

1. ​​分词器选型​​：默认分词器对中文不友好，需安装 ik 插件
2. ​​数据同步一致性​​：双写时用 canal 监听 MySQL Binlog 更可靠
3. ​​ES 动态映射陷阱​​：字段类型自动推断可能导致查询异常，建议预定义 mapping

---

​​总结​​：

• ​​简单 CRUD​​：继续用 MyBatis-Plus，别过度设计
• ​​复杂搜索/聚合​​：ES 是真香，但要做好​​资源隔离+监控​​（ES 吃内存大户！）
• ​​混合架构​​：学会在不同场景选择合适工具，​​没有银弹​