dql是面向php实体类的查询语言，操作类与属性而非表字段，天然解耦数据库；不支持select子句子查询等sql功能，参数绑定更严格，性能差异源于缓存机制与执行路径不同。
DQL 是面向对象的查询语言，SQL 是面向数据库表的指令
DQL（Doctrine Query Language）不是 SQL 的变体，它不操作表、字段或 JOIN 语法，而是操作 PHP 实体类和属性。比如 SELECT u FROM App\Entity\User u 中的 User 是类名，u 是实体别名，u.email 对应的是实体的 $email 属性——Doctrine 会自动翻译成对应表的 user.email 字段。而原生 SQL 必须写 SELECT * FROM user WHERE email = ?，直接面对物理结构。
这意味着：DQL 天然隔离数据库细节，换 MySQL 或 PostgreSQL 不用改查询；SQL 则强绑定表名、字段名、函数名（如 DATE() vs TO_CHAR()），迁移成本高。
DQL 不支持所有 SQL 功能，子查询和 SELECT 嵌套有硬限制
DQL 允许在 WHERE 或 HAVING 中用子查询，但仅限两类：
-
EXISTS (SELECT ...)判断存在性 -
u.id IN (SELECT u2.id FROM ...)或标量结果（如AVG()） - 不能在
SELECT子句中写子查询，例如SELECT u.name, (SELECT COUNT(*) FROM order o WHERE o.user_id = u.id) AS orderCount在 DQL 里非法
这类需求必须退回到原生 SQL，用 $conn->executeQuery() 配合 ResultSetMapping 手动映射字段，否则会报 QueryException: Invalid PathExpression 或解析失败。
参数绑定方式一致，但 DQL 更严格防注入
两者都要求用占位符 + setParameter()，禁止字符串拼接：
- DQL：
WHERE u.status = :status→->setParameter('status', $input) - 原生 SQL：
WHERE u.status = ?→->executeQuery($sql, [$input])，或命名参数:status - 错误示范：
"WHERE u.status = '" . $input . "'"—— 无论 DQL 还是 SQL，都等于裸奔
但 DQL 还额外拦住一类风险：无法参数化的部分（如 ORDER BY 字段、IN 列表长度、表名）必须白名单校验+类型强转。比如动态排序方向只能写 ORDER BY u.name ' . ($dir === 'DESC' ? 'DESC' : 'ASC')，不能直接插变量。
性能差异不在语法层，而在缓存与执行路径
DQL 查询会经过 Doctrine 的编译层：DQL → SQL → 执行 → 结果映射。这个过程带来两层可缓存点：
-
query_cache：缓存 DQL 到 SQL 的转换结果（适合固定结构、变参少的查询） -
result_cache：缓存最终数据行（适合读多写少、时效宽松的场景） - 原生 SQL 绕过 DQL 编译，没法用
query_cache，但可直连 DBAL，省去对象映射开销
所以不是“DQL 慢”或“SQL 快”，而是：简单列表查优先用 DQL + result_cache；复杂分析、窗口函数、跨库关联，就该切原生 SQL，别硬扛。
真正容易被忽略的，是 DQL 报错时堆栈往往不指向你写的 DQL 字符串，而是 Doctrine 内部解析器——这时候得先检查别名是否重复、子查询是否用了外层别名、GROUP BY 是否漏了非聚合字段，而不是急着翻 SQL 文档。
