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

大家好，我是月白。

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

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

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

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

别急，让我简单介绍一下
mysql 的这个痛点，用 elasticsearch 轻松解决

问题简述

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

表结构

客户表 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查询数据，这样对整个业务逻辑改动最小，效率也完全没有问题，毕竟原来的查询及组装数据逻辑十分复杂，涉及到五六张表联查和后续数据处理，实在不想做过多改动（常规职场保命）
mysql 的这个痛点，用 elasticsearch 轻松解决