Symfony2数据库查询需分阶段优化：入门用配置+生成实体+仓库方法；进阶防N+1、正确写关联与动态条件；架构层重解耦、环境适配与可维护性；工具选择依场景而定，Doctrine本质是对象关系翻译官。
想在 Symfony2 里把数据库查询用得又快又稳，关键不是堆功能，而是分阶段做对事：入门先跑通“类→表→查”的闭环，进阶盯住关联加载和动态条件的写法，到架构层则聚焦解耦、可维护和环境适配。Doctrine 不是 SQL 封装器，它是对象与关系之间的翻译官——用对时机、选对工具，比背语法重要得多。
入门：三步跑通首次查询
不碰 DQL，也能完成 80% 的基础操作：
- 配置数据库连接：在 parameters.yml 写好 host、dbname、user、password；再在 config.yml 的 doctrine.dbal 段引用这些参数；运行 php app/console doctrine:database:create 创建库
- 生成实体与表：用 doctrine:generate:entity 创建 Product 类，交互式添加 name、price 等字段；再执行 doctrine:schema:update --force 同步建表
- 调用仓库方法查数据：在 Controller 中获取 Repository，直接用 find($id)、findOneBy(['status' => 1])、findBy(['type' => 'book'], ['createdAt' => 'DESC']) —— 这些方法够用、安全、无需拼接字符串
进阶：避开 N+1，写对关联与动态条件
列表页变慢、接口超时，往往卡在这几个细节上：
- 多层嵌套时，别靠循环中调 $user->getPosts() —— 改用 leftJoin('u.posts', 'p') + addSelect('p.title') 一次性拉取所需字段
- 多对多“同时满足多个条件”（如红色+大号），必须为每个条件单独 join('p.attributes', 'a0') 和 join('p.attributes', 'a1')，别名和参数名都不能复用
- 动态搜索条件（价格可空、状态可选）别反复调 andWhere()，改用 $expr = $qb->expr() + $andX = $expr->andX() 统一收集，最后 where($andX)
- 要字段不要对象？开头用 select('u.id', 'u.email')，补字段用 addSelect('p.title')，结尾务必调 getScalarResult() 跳过对象构建
架构：让查询逻辑可维护、可移植、可诊断
上线前必须检查这几项硬约束：
- 容器化部署时，database_host 必须填服务名（如 db），不能写 localhost；文件上传目录权限要在启动脚本中显式 chown -R www-data:www-data web/uploads
- 业务中涉及数据变更的环节（如用户注册成功），改用事件分发器解耦：定义 UserRegisteredEvent，邮件、统计、头像初始化等服务各自监听，主流程不动
- 所有路径、域名、超时值都抽到 parameters.yml，禁止硬编码；视图类实体需手动标注 @ORM\Entity(readOnly=true)，并在 Repository 中封装专用查询
- 开发环境打开 Web Profiler，点开 Database 面板看 SQL 总数——若返回 20 条记录却执行了 45 条 SQL，基本就是 N+1；点击每条 SQL 查 “Explain”，确认是否命中索引
延伸：该用什么，不该用什么
工具不是越多越好，而是用得恰到好处：
- 实体仓库方法：适合单表固定条件，比如后台列表筛选、详情页加载
- DQL：跨表关联、聚合统计（COUNT/SUM）、需要精确控制查询结构时使用；永远用 setParameter() 绑定变量
- QueryBuilder：条件动态组合、分页、排序场景首选；链式调用清晰，不易出错
- 原生 SQL：仅限迁移脚本、报表导出、ORM 明确不支持的操作；通过 doctrine.dbal.default_connection 获取连接，严禁字符串拼接
- 视图映射：把复杂 JOIN 或计算逻辑下沉到数据库层，映射为只读实体，在 Repository 中封装方法调用，简化上层代码
