本文详解如何使用 doctrine querybuilder 对自引用实体的子记录进行聚合计算（如求和），实现“已完全卖出”或“部分卖出”交易的精准筛选，并规避浮点精度问题与 n+1 查询风险。
本文详解如何使用 doctrine querybuilder 对自引用实体的子记录进行聚合计算（如求和），实现“已完全卖出”或“部分卖出”交易的精准筛选，并规避浮点精度问题与 n+1 查询风险。
在构建金融类应用（如股票交易系统）时，常需处理具有层级关系的交易数据：一笔买入交易（parent）可对应多笔卖出交易（children），且需根据子交易的累计成交金额（executed）与父交易原始金额进行比对，以判断其状态为“完全卖出”“部分卖出”或“未卖出”。
虽然 Doctrine 的 OneToMany 关系能方便地加载子实体（如通过 fetch: 'EAGER'），但直接在 PHP 层遍历并累加会导致性能严重下降（N+1 查询、内存占用高、无法利用数据库索引）。正确做法是将聚合逻辑下推至数据库层，使用 SQL 的 GROUP BY + HAVING 实现高效筛选。
✅ 正确实现：使用 INNER JOIN + GROUP BY + HAVING
以下 TradeRepository::findSoldTrades() 方法返回所有已完全卖出的买入交易（即子交易 executed 总和等于父交易 executed）：
public function findSoldTrades(): array
{
return $this->createQueryBuilder('t')
->innerJoin(Trade::class, 's', 'WITH', 's.parent = t')
->groupBy('t.id')
->having('SUM(s.executed) = t.executed')
->orderBy('t.created', 'ASC')
->getQuery()
->getResult();
}? 关键说明：
- innerJoin(Trade::class, 's', 'WITH', 's.parent = t') 显式关联子交易（避免 ON 子句硬编码 ID 字段），语义清晰且兼容 Doctrine 的关联映射。
- groupBy('t.id') 确保按父交易分组，使 SUM(s.executed) 按每个买入交易独立计算。
- having(...) 在分组后过滤，替代低效的 WHERE 子查询 —— 这正是比原始 SQL 更“优雅”的核心所在。
⚠️ 重要注意事项
-
数据类型必须使用 DECIMAL
原问题中 price 和 executed 使用 float 类型会导致浮点精度误差（如 0.1 + 0.2 !== 0.3）。务必改为数据库 DECIMAL 类型，并同步更新实体注解：#[ORM\Column(type: 'decimal', precision: 15, scale: 4)] private \Decimal $executed; // 或 string / float 转换时严格处理
-
区分“完全卖出”与“部分卖出”
若需同时获取两类交易，可扩展为两个方法：// 完全卖出 ->having('SUM(s.executed) = t.executed') // 部分卖出（有子交易但未卖完） ->having('SUM(s.executed) < t.executed AND COUNT(s.id) > 0') 空子集交易（未卖出）不参与 JOIN
INNER JOIN 天然排除无子交易的记录。若需包含“未卖出”交易，应改用 LEFT JOIN 并配合 IS NULL 或 COALESCE(SUM(...), 0) 处理。-
性能优化建议
- 为 parent_id 字段添加数据库索引（Doctrine 默认不自动创建外键索引）：
#[ORM\ManyToOne(targetEntity: self::class, inversedBy: 'children')] #[ORM\JoinColumn(onDelete: 'CASCADE', nullable: true, name: 'parent_id', referencedColumnName: 'id')] private ?self $parent = null;
- 在迁移中显式添加索引：CREATE INDEX IDX_TRADE_PARENT ON trade (parent_id);
- 为 parent_id 字段添加数据库索引（Doctrine 默认不自动创建外键索引）：
✅ 总结
聚合计算不应留在应用层，而应由数据库高效完成。通过 innerJoin + groupBy + having 组合，不仅能精准表达业务逻辑（如“卖出总和等于买入金额”），还能获得极佳的查询性能与可维护性。同时，谨记金融场景下 DECIMAL 的不可替代性 —— 这不是优化项，而是正确性底线。
