2.5s 对于数据量大、网络状态不好的话，算正常吧。

需要进一步确认时间卡在哪里：
连接？索引？数据汇合？数据传输？客户端显示？

把 explain 贴出来看看, 如果里面有 hash semi join ,那就说明是机器性能太差了, 否则就是 sql 要改.

exists 不一定最优，A exists B ，A 的数据量大，不要考虑 exists ，大多数情况下一定有条件，不可能查询所有有关联的 A 的信息，可能 A 的数据量有 20w ，不可能统一都给前端把，还是得看场景

子查询还不如 join 呢

可以贴下 SQL ，我现在用 PG ，交易表大概 4000W 条数据，有个终端表大概几 W ，也是用 JOIN 方式。后来想改为 IN 条件，但是条件太多会造成索引失效。还是要具体问题具体对待

先查 id 集合，再用 id 查完整数据

分页查询，有 limit,关联字段有索引应该不会慢呀， 主要就是查处满足条件的 a 数据再做关联，避免全量关联就会快很多，确认走到索引了吗？

先从 B 中查出 需要的 A 的 id ，
with queryB as(
select distinct(A.id) from B where  xxx)

select  * from A INNER JOIN  queryB on  queryB.AID= A.ID

我也有类似的疑惑。MySQL 中查询

select r.* from t_event_record r inner join t_event_workflow_record wr on r.id = wr.event_id
where wr.user_id = 1 and wr.status= 1
group by r.id order by r.create_time desc limit 10

主表 10w 数据 子表 40w+ 就这查询就需要 500ms
count 查询一样的需要 500 ms
explain 一个 index 一个 ref 慢的不得了
就疑惑的很是不是查询就这么慢。

A 订单 240w, B sku 720w, 比你慢点