mysql 的这个痛点，用 elasticsearch 轻松解决

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《mysql 的这个痛点，用 elasticsearch 轻松解决》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

大家好，我是月白。

写这篇文章不是对比 mysql 和 elasticsearch 的优劣（它们生而不同，没啥好比的），而是想分享一下最近在工作上遇到的一个查询问题和这个问题的解决过程。对于 elasticsearch，我也还是处在略懂阶段，要不是因为这次工作需要，我可能不会去研究它?
​

好了，回到正题，由于内部工作调整，接收了一个公司的边缘项目，体量并不大，几十万的用户数量。然而，就是这区区的几十万用户数量，导致了mysql in 查询参数过多的问题，运营在管理后台查询客户列表速度缓慢甚至一度陷入瘫痪。
​

你可能会想，是不是代码写的太烂了或者前期设计考虑不周？

其实这个也能理解，毕竟产品的需求是多变的，考虑不周是常有的事。这个列表查询原本只有几个简单的字段查询，而且都是客户表单表内的字段查询，随着产品的变更，查询条件多达十几个，其中这个标签查询，联表也解决不了问题，那具体是怎么一个情况呢？

别急，让我简单介绍一下

问题简述

为了集中于描述这个问题，表结构进行了惨无人道的简化，能体会到这个意思就好?
前端的展示就是下面这种分页表格（图片截图自 ant design 官方文档）

表结构

客户表 custmers

字段	类型
id	int
name	string
gender	tinyint
age	int
remark	string
created_at	timestamp
updated_at	timestamp

标签表 tags

字段	类型
id	int
name	string
created_at	timestamp
updated_at	timestamp

关联表 customer_tag

字段	类型
customer_id	int
tag_id	int

查询需求

现在产品需要通过客户名字以及客户身上的标签进行查询，支持多个标签同时查询。原来的sql大概是这样的

/*
 获取符合要求的 customer_id 列表 
 查出来一大堆 customer_id
 */
select customer_id from custmer_tag where tag_id in (传入的tag_id);

/*
 通过 customer_id 查询
 每翻一页都得经历这一大堆id的in查询，id过多还会导致代码直接崩溃
*/
select * from customers where id in (一大堆id) limit 10 offset 0; 

问题显而易见了吧，in 查询内参数过多，不仅效率低下，极端情况还会导致sql过长程序崩溃。
​

看了第一眼我觉是不是可以拯救一下（慢就慢一点，先让程序不异常），于是换成下面的语句：

select * from customers where id in (select customer_id from custmer_tag where tag_id in (传入的 tag_id) group by customer_id));

但是仔细看了一下业务逻辑我就放弃了，多个 tag_id 查询 要支持 and 和 or 的查询逻辑，

select customer_id from custmer_tag where tag_id in (1,2,3) group by customer_id

这句子查询 sql 就是 or 关系查询，customer 只需要存在任何一个 tag_id 就满足查询条件。但是如果是 and 逻辑呢？要查出同时存在标签 1，2，3 的客户，那么这条语句就不适用了。当然，如果一定要用 sql 去查，也许也能查出来，这里我就没有再试了，毕竟就算子查询行得通，效率也是十分低下的，不是长久之计。

解决方案

那该如何解决呢？我的第一反应就是先通过 es 查询出符合条件的 customer 表的 id，然后再通过id查询数据，这样对整个业务逻辑改动最小，效率也完全没有问题，毕竟原来的查询及组装数据逻辑十分复杂，涉及到五六张表联查和后续数据处理，实在不想做过多改动（常规职场保命）

开始优化

搭建 elasticsearch 服务

这个是运维的活，我提需求就行了。

数据写入 es

这个得我干了?
由于需要查询的字段涉及了多张表，索性把所有相关字段和customer的基本信息写入到 es，方便后续同样需要查询的业务（后面还真的用到了，而且还追加了字段）
​

字段确定了之后，如何实时更新呢？在每个业务修改和插入的点触发写入和更新的操作？
显然不是，这样写既容易写不全面，也需要很大的机械化工作，显然不是生活在水深火热之中的程序员该干的事。那么怎么做呢？
​

这时候，如果我们能像mysql从库那样，把数据都同步过来，然后我们更新一下 es，岂不是完美。说干就干，在通过一番折腾之后（主要是监听binlog），终于是解决了数据入库的问题。

重构代码

现在的代码逻辑变成了这样：

1. 从 es 分页查询出 customer id 100， 200， 300
2. 把原来 sql 的所有 where 条件删除，添加 where id in (100,200,300)，其他逻辑不用动

至此，业务重构完成，查询速度轻轻松松提高百倍，那缺点是什么呢？
​

！！！要花钱！！！！！

​

后话

虽然问题目前是解决了，但从这件事中，我体会到了 es 便利之处，决定进一步学习一番。这篇文章涉及到的 es 和 mysql 监听等相关内容后续更新吧！
​

就酱，祝大家工作顺利！我是月白，一枚在互联网苟且偷生的猿。

好了，本文到此结束，带大家了解了《mysql 的这个痛点，用 elasticsearch 轻松解决》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！