[求教] 阿里 Java 编程规范：避免使用 IN。 那这个业务场景不用 IN 还有什么好方案么？

[bubuXiaoqi]

公司里面有 10W 个客户，员工 A 负责其中 2W 个客户。 (数据在用户库里面)

现在 员工 A 要查询 [自己负责的所有客户] 的实时交易明细。(数据在订单库里面，和用户库是两个实例)

目前的方案是查这 2W 的客户的 ID，然后在交易明细里面进行客户 IDS 的过滤。

但是这样 IN 的内容就特别大，而且可能还会变大。今天看到 JAVA 编程规范里面说避免使用 IN，那这样还有什么好办法么。

因为 员工看自己负责的客户的 账户、订单、交易、等业务表太多太多了。每个表目前都是 in ids 的方案。

[bubuXiaoqi]

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

[wfd0807]

换一个思路，楼主描述的“ 员工 A 要查询 [自己负责的所有客户] 的实时交易明细”，这个需求真的没有问题吗？
实时交易明细，是全部的交易明细吗？如果是的话，批量查询 2w 用户的全部交易明细的目的是啥呢？就算给员工 A 实现了这种查询，你确定有意义吗？我敢打保票，他会在点查询按钮之前，先筛选用户

[bubuXiaoqi]

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

[buster]

如果现在 in ids 的代码还可以支撑运行，那完全可以考虑把所有的表都放在一个库里，之后使用 join 来解决 in ids 的问题，之后再考虑优化查询效率（逻辑、索引、分库分表）

[wfd0807]

@bubuXiaoqi 所以，你这个需求的真相是想查看再加工数据和报表，这应该通过 BI 手段是实现

[wfd0807]

@bubuXiaoqi ps，目前的分库方案没看出来有什么实际应用上的优势，如果不分库的话，楼上都说明了，join 可以解决 in ids 的问题，慢就优化，就算优化需要分库分表了，也不应该是现在这种分

[jorneyr]

冗余列存储关系

[admol]

交易明细里面记录下员工 A 的 Id ？

[clf]

其实感觉就是你们的业务数据存储的方式（数据结构）出了问题。另外就是分库分的看上去像徒增成本。跨服务器间查询会有连接成本的。

你们用户标签估计是用逗号分隔丢在一个字段里的？也不知道员工会不会负责多个标签。

其实也可以考虑引入 Elaticsearch，存进 Mysql 的数据都同步进去，员工搜索用户信息的时候放在 ES 里进行。

[yitingbai]

我也为这个问题头疼, 似乎没有比 in 更好的方法, 因为 in 太好用了

[lidashuang]

redis set

[geminius2333]

收藏一波，看看大佬们的回复

[bubuXiaoqi]

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

[TomVista]

客户的标签可以修改吗？ 是不是可以构建一个 员工-标签-订单的关系？

[bubuXiaoqi]

@TomVista 客户的标签可以修改

[zoharSoul]

拉到 es 里面搜索, 搜到到 id 回 mysql 查

[bubuXiaoqi]

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

[hmdsw]

exists?

[glacial]

@bubuXiaoqi 建一张员工与客户的关联表, 到你订单库里，然后通过 消息中间件或 cdc 同步这张关联表

[PiersSoCool]

分批 in

话说这种数据肯定没有意义，这么多数据，能看得过来吗？一次看 2000 * 交易量的数据，怕不是真需求...