DQL与原生SQL在Symfony2中是分层协作而非替代关系：DQL面向实体与业务逻辑，适用于关联查询、缓存集成、聚合统计及动态条件；原生SQL面向性能与数据库能力，适用于跨库联查、复杂报表、批量操作及审计场景。
DQL 和原生 SQL 在 Symfony2 中不是“二选一”的替代关系，而是分层协作的工具：DQL 是 Doctrine 的标准查询语言，面向实体与业务逻辑；原生 SQL 是绕过 ORM 的底层通道，面向性能与数据库能力。选哪个，关键看你要解决什么问题。
什么时候该用 DQL？
DQL 本质是“用对象思维写查询”，它把表、字段、JOIN 等概念映射为实体、属性和关联关系，由 Doctrine 自动翻译成适配当前数据库的 SQL。适合绝大多数业务场景。
- 跨实体关联查询（如 User → Post → Comment），DQL 写法简洁清晰：
SELECT u, p FROM User u JOIN u.posts p WHERE p.status = :status - 需要利用 Doctrine 缓存（如 result cache）、事件监听（preSelect）、生命周期管理时，只有 DQL 或 QueryBuilder 触发的查询才被纳入 ORM 流程
- 聚合统计（COUNT、SUM、AVG）配合 GROUP BY 且结果需映射为数组或标量值，DQL 提供
getSingleScalarResult()等安全方法 - 查询条件动态组合但结构稳定（如后台搜索页），配合 QueryBuilder 使用更易维护、防注入
什么时候必须用原生 SQL？
原生 SQL 是“放弃 ORM 抽象，直连数据库”。它不经过实体元数据解析、不触发事件、不走一级/二级缓存，但换来的是完全控制力和性能上限。
- 跨数据库实例联查（如主库
users+ 从库logs），Doctrine 不支持多连接 JOIN，只能靠应用层分查或 DBA 协作建视图/FEDERATED 表 - 复杂报表类操作：窗口函数（
ROW_NUMBER() OVER）、CTE（WITH RECURSIVE）、存储过程调用、全文索引高级语法等，DQL 无法覆盖 - 批量更新/删除海量数据（如清理百万级日志），DQL 的
UPDATE/DELETE虽可用，但若涉及多表 JOIN 条件或 MySQL 特有语法（如DELETE t1 FROM t1 JOIN t2...），原生 SQL 更直接可靠 - 数据库迁移脚本、初始化数据、DBA 要求强审计的场景，SQL 明确、可复现、易审查
关键差异与风险提醒
两者在安全性、可移植性、调试成本上差异明显，不能只看“能不能跑”。
-
参数绑定方式不同：DQL 必须用
setParameter('key', $val)；原生 SQL 推荐用?占位符（DBAL 支持）或命名参数，严禁字符串拼接，否则直接暴露 SQL 注入风险 -
数据库可移植性：DQL 生成的 SQL 由 Doctrine 根据方言（MySQL/PostgreSQL/SQL Server）自动适配；手写原生 SQL 若含特定语法（如 MySQL 的
INSERT ... ON DUPLICATE KEY UPDATE），换库就得重写 -
调试难度：DQL 错误提示常指向 AST 解析失败，需结合 Doctrine 日志（
doctrine.dbal.logging: true）看最终生成的 SQL；原生 SQL 错误直接来自 PDO，定位快但缺乏上下文 -
表名/字段名大小写：macOS 与 Windows 对标识符敏感度不同，DQL 和 QueryBuilder 会自动加反引号或双引号；手写原生 SQL 时需自行处理，建议统一小写+下划线并配置 MySQL
lower_case_table_names=1
