findall() 慢是因为默认全表扫描且无优化，等价于 select * from table，不加条件、不限制、不走索引，导致大数据量时内存与数据库压力剧增。
findAll() 慢，不是方法本身有问题，而是它默认不做任何优化——它只是把整张表全量查出来，不管你要不要、用不用。
为什么 findAll() 会触发全表扫描
Doctrine 的 findAll() 底层等价于 SELECT * FROM table，不加 LIMIT、不加 WHERE、不走索引（除非主键被隐式用上）。一旦表里有几万行，PHP 还得把每行映射成 Entity 实例，内存和数据库压力就上来了。
- 它不区分“只读列表”和“需要编辑的完整对象”，一律加载全部字段 + 全部关联代理
- 如果实体带
@ORM\OneToMany关联，默认是惰性加载，但findAll()后只要有人调用了$entity->getChildren()，就会批量触发 N+1 查询 - MySQL/PostgreSQL 对全表扫描没有 magic 优化——数据量翻倍，耗时基本也翻倍
替代 findAll() 的三种实操方案
别删掉 findAll()，但别在列表页、API 响应、后台导出里直接用它。
- 查 ID 列表用
createQueryBuilder()+select('e.id')：省掉字段映射开销，结果集小 5–10 倍 - 分页场景强制加
->setMaxResults(25)->setFirstResult(0)，哪怕你暂时没做前端分页，也先兜住数据量 - 需要展示关联字段（比如用户+部门名）时，用
leftJoin()+addSelect()一次性查出，而不是靠循环里调$user->getDepartment()->getName()
容易被忽略的性能陷阱
你以为改了查询就完事？这些点常让优化失效：
-
findAll()返回的是ArrayCollection，但如果你后续用array_filter($list, fn($u) => $u->getStatus() === 'active')，等于把全量数据拉进 PHP 再过滤——数据库本可以干这事 - Twig 模板里写
{% for user in users %}{{ user.profile.avatarUrl }}{% endfor %}，会逐个触发懒加载，变成 N 次查询 - 开发环境开了
debug: true，Profiler 默认记录所有查询，findAll()调一次，Profiler 就多记几百行日志，拖慢感知速度（但不是真实 DB 慢）
真正卡住的往往不是 findAll() 这一行代码，而是它后面那串没意识到的隐式行为。
