@opengps 不用 join 第一是因为不在一个数据库实例 第二是因为 员工-标签-客户 已经是 4 5 个表的关联。这一块是可以缓存数据的。 全在数据库查的话 关联的就更多了 而且也看起来可读性很差。 实在要关联还得再单独维护一张员工->客户 IDS 的表。

@romisanic 我感觉也确实是只能 聚合数据到 es 然后考虑到各种分页情况 字段都提前设计好了。 额外还有一个 es 数据和 mysql 数据的一致性成本

@zoharSoul 如果业务重新设计的话 可能会这样做， 但是这样做不了分页。比如把 T1 表的数据放入 ES 了 ，业务有的需要进行 T1 T2 的关联过滤分页查询。就做不到了。

@TomVista 客户的标签可以修改

@lychs1998 员工 标签 和客户是三张表和两个映射表。 用 es 的话主要是设计的业务表太多了 都得弄一份 太麻烦了。。

@wfd0807 比如说 我要看我今天所有客户产生的明细或者明细的报表 ，这个时候我只有时间段的 不会针对到具体的客户的

@Jooooooooo 你的意思 最合适的还是关联表查询过滤么

@Jooooooooo 有一个参数可以改 in 的内容的值。我目前改的不小。但是这个方案本身好像不长久。而且性能也不行

@biuaxia 1

@buster 最早的时候所有数据库都在一起的时候。效率都挺差的 因为数据挺多的。 除非针对每个 SQL 针对性的给索引 不然大表间关联 之前用的也很慢

@statement 分批 in 的话 不仅数据要进行汇合 。而且面对过滤分页的场景处理不了。

@eason1874 这个方案还是要进行数据库的关联过滤么。 但是大表关联大表 之前没有拆之前就是关联查询的 效果好差。

@a target="_blank" href="/member/Jooooooooo" rel="nofollow noopener">Jooooooooo 对 所以现在很头疼

@lychs1998 员工和客户的关系是会变的 而且一个客户可能会被多个员工负责。。。 就是员工负责 部分标签的客户。 所以不同的员工可能都会负责同一个标签

@lychs1998 主要数据量也非常大。 哪怕都在同一个数据库 in 太多了用不上索引速度都很慢

用户、订单、商品 等都是单独部署的服务器和数据库

@BBCCBB 因为在不同的数据库实例里面了。所以没有办法用 join

荣耀 30s

xps 13
hp spectre
huawei mate book x pro
如果用 iphone 就买个苹果电脑吧 我觉得大学生用 mb 不实用也不好玩游戏 可能还是要装双系统或者刷成 win(我身边很多买苹果刷 windows 的女生。。。。)