Yii2 ActiveRecord性能优化核心是避免N+1查询，应使用with()预加载、DataLoader解决GraphQL场景、慎用select+save防止数据污染，并在批量操作中优先选用QueryBuilder。
Yii2 的 ActiveRecord 用起来顺手，但一到高并发或复杂关联场景，性能就容易“掉链子”——最典型的就是 N+1 查询。这不是框架不行，而是没用对方式。核心在于：别让循环里的每个对象都自己去查一次数据库。
预加载关联数据，别等遍历时才查
当你要展示用户列表及其头像、角色、订单数时，如果写成这样：
错误示范：
$users = User::find()->all();
foreach ($users as $user) {
echo $user->profile->avatar; // 每次触发一次 SELECT FROM profile
echo $user->ordersCount; // 每次触发一次 COUNT 查询
}
这就立刻变成 N+1。正确做法是用 with() 或 joinWith() 一次性把关联数据捞上来：
- 一对多（如用户→订单）：用
User::find()->with('orders')->all()，ActiveRecord 会自动合并为 2 条 SQL（1 次 users，1 次 orders 批量 WHERE id IN (...)） - 多对一（如订单→用户）：用
Order::find()->with('user')->all()，同样只发 2 条 SQL - 需要关联字段参与 WHERE 或 ORDER：改用
joinWith('user', true, 'LEFT JOIN')，并显式 select 字段避免冗余
GraphQL 场景下，ActiveRecord::with() 基本失效
在 GraphQL Resolver 中，每个字段 resolver 是独立调用的，with() 没法跨 resolver 共享上下文。比如查 10 个商品，再为每个商品查其分类 —— 默认就会发出 10 次分类查询。
这时必须引入 DataLoader，它能把同一类查询聚合成一次批量请求：
- 每次请求新建一个 DataLoader 实例（不能复用全局单例）
- 把 loader 挂到
$context上，所有 resolver 都能访问 - batch callback 里统一用
Category::find()->where(['id' => $keys])->indexBy('id')->all() - 返回数组 key 必须严格对应 $keys 顺序，缺项也要补 null，否则 GraphQL 报错
慎用 find() + save() 加载不全字段
ActiveRecord 默认 select *，但有时为了性能只查部分字段，例如：User::find()->select(['id', 'status'])->where(['id' => 123])->one()。此时对象只含 id 和 status，其他属性是默认值（如 name = null、email = ''）。
如果后续直接 $user->save()，这些默认值会覆盖数据库原值 —— name 变成 null，email 变成空字符串，造成静默数据污染。
安全做法有三种：
- 明确需要更新哪些字段，用
$user->save(false)跳过验证，再手动赋值要改的属性 - 改用
updateAll()直接执行 SQL 更新，绕过模型层 - 自定义 save() 行为：重写
beforeSave()，检查当前对象哪些属性被真实赋值过，只保存那些字段
批量操作优先用 QueryBuilder，少依赖 ActiveRecord
ActiveRecord 适合单条记录的 CRUD，但面对千条数据导入、状态批量更新、统计汇总等场景，它的对象封装反而拖慢性能。
更高效的方式是绕过模型，直连 QueryBuilder：
- 批量插入：用
createCommand()->batchInsert()，比循环 new Model()->save() 快 5–10 倍 - 批量更新：用
createCommand()->update()+ WHERE 条件，避免逐条 load-modify-save - 聚合统计：用
createCommand()->queryScalar()或queryAll()，不走模型实例化开销 - 复杂多表关联分析：用 QueryBuilder 构建 JOIN + GROUP BY，比嵌套 with() 更可控、更易加索引
