Yii2 viaTable关联按中间表排序为何执行2次查询而非JOIN

1. 两次查询逻辑的设计原因 #

Yii2的这种设计并非反直觉，而是ActiveRecord架构下的权衡结果，核心原因有三点：

• 保证模型的纯净性：ActiveRecord要求每个返回的模型实例仅对应单表的字段，直接JOIN查询如果出现同名字段会导致属性覆盖，后续的模型修改、验证逻辑也会出现不可预期的问题。
• 预加载场景下的效率优势：当你批量查询多个主模型（比如一次性查100个kit的关联分类）时，JOIN会产生大量重复的主表数据，结果集会急剧膨胀。两次查询的逻辑是先拉取所有主模型ID，再批量查关联数据最后做映射，整体传输和处理的数据量远小于JOIN方案，效率更高。
• 规则隔离：关联表和主表可能各自有软删除、默认查询范围、权限过滤等逻辑，拆分两次查询可以让各自的查询规则独立生效，避免JOIN时的条件冲突。

2. 和懒加载/预加载的关联，以及joinWith的差异 #

你的猜测是对的：

• 懒加载场景下，确实是你访问关联属性$kit->categories时才会触发两次查询，先取关联ID再拉取对应模型数据；预加载用with('categories')批量查询时，也是复用的这套逻辑，只是会把所有主模型的关联ID合并到同一个IN查询里，减少查询次数。
• 用joinWith()替代的话效果完全不同：joinWith会直接生成JOIN语句做单查询，你可以直接在关联定义里加上中间表的排序规则，不需要额外加JOIN，也不会出现IN查询排序失效的问题，更符合你的需求。
  另外补充一个更轻量的实现方案：你不需要额外加JOIN，只要在拿到关联结果后，按照第一次中间表返回的ID顺序手动重排分类数组即可，实现更简单，查询开销也更低。

3. 大关联量下的性能问题 #

你当前的写法在关联量较大时确实有性能隐患：

• 你的实现额外加了一次LEFT JOIN，且WHERE条件重复（同时写了kitId过滤和IN条件），虽然数据库优化器大概率会优化冗余条件，但JOIN本身的开销是额外增加的。
• 当关联量达到数千级别时，IN条件里的数千个ID会导致数据库查询效率明显下降，额外的JOIN会放大这个问题。
  如果后续要适配大关联量场景，推荐两种优化方案：
• 小量级关联（千级以内）：用手动重排结果的方案，省掉JOIN开销
• 大量级关联：直接用joinWith做单查询，配合索引优化查询效率，关联量过万的话必须加分页，不能一次性拉取全量数据。

内容的提问来源于stack exchange，提问作者Rick Kukiela