关于mysql: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 查问数据，这样对整个业务逻辑改变最小，效率也齐全没有问题，毕竟原来的查问及组装数据逻辑十分复杂，波及到五六张表联查和后续数据处理，切实不想做过多改变（惯例职场保命）

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

这个得我干了😅
因为须要查问的字段波及了多张表，索性把所有相干字段和 customer 的根本信息写入到 es，不便后续同样须要查问的业务（前面还真的用到了，而且还追加了字段）

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

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

当初的代码逻辑变成了这样：

从 es 分页查问出 customer id 100，200，300
把原来 sql 的所有 where 条件删除，增加 where id in (100,200,300)，其余逻辑不必动

至此，业务重构实现，查问速度轻轻松松进步百倍，那毛病是什么呢？

！！！要花钱！！！！！

尽管问题目前是解决了，但从这件事中，我领会到了 es 便当之处，决定进一步学习一番。这篇文章波及到的 es 和 mysql 监听等相干内容后续更新吧！

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

关于mysql:mysql-的这个痛点用-elasticsearch-轻松解决

问题简述

表构造

查问需要

解决方案

开始优化

搭建 elasticsearch 服务

数据写入 es

重构代码

后话