orm 查询慢的主因是 n + 1 问题，而非 php 8.5 版本；应优先用 with 预加载、检查配置如代理类生成与查询日志，并在 sql 复杂时才转向原生。
PHP 8.5 中 ORM 查询慢得明显，先查是不是 N+1
ORM 慢的头号嫌疑不是 PHP 版本，也不是框架本身，而是没意识到自己在循环里反复触发 SELECT。比如遍历用户列表时，对每个用户调用 $user->posts，结果发了 101 条 SQL（1 条查用户 + 100 条查文章）。
实操建议：
- 用数据库查询日志或
Xdebug+pdo::ATTR_EMULATE_PREPARES = false看真实执行语句数 - Laravel 用
with('posts')，Doctrine 用$qb->leftJoin('u.posts', 'p')，提前载入关联 - 避免在模板层（Blade/Twig）中访问未预加载的关联属性
- PHP 8.5 的 JIT 对这种 I/O 密集型场景几乎无加速效果，别寄希望于版本升级“自动变快”
原生 PDO 查询比 ORM 快多少？看的是执行阶段，不是写法
原生 PDO 不一定更快——如果 ORM 生成的 SQL 和你手写的完全一样，且参数绑定、连接复用、缓存策略一致，性能差异通常在 5% 以内。真正拉开差距的是：你有没有手动优化 SQL，而 ORM 默认没做。
常见错误现象：
立即学习 “PHP 免费学习笔记（深入）”；
- ORM 自动生成
SELECT *，但业务只用 2 个字段 → 手写改用SELECT id, title - ORM 默认不加
USE INDEX或FORCE INDEX，大表 JOIN 时优化器选错索引 → 原生可硬编码提示 - 批量插入时 ORM 逐条
INSERT，而原生可用INSERT INTO …… VALUES (……), (……) - PHP 8.5 的
mysqli扩展已支持mysqlnd的异步查询，但主流 ORM 还没适配，原生能压榨这点
PHP 8.5 下 Doctrine/Laravel Eloquent 的性能开关要手动开
PHP 8.5 自身不改变 ORM 行为，但默认配置在高并发下容易暴露瓶颈。很多项目跑着没感觉，一上生产就卡，问题出在几个关键配置没调。
必须检查的点：
-
doctrine.orm.auto_generate_proxy_classes在生产环境必须关，否则每次请求都尝试生成代理类，IO 开销陡增 - Laravel 的
DB::connection()->enableQueryLog()绝不能留在生产，它会累积内存并拖慢所有查询 - 启用
opcache.preload后，确保 ORM 的实体类和 Repository 类被预加载，否则反射开销在 PHP 8.5 下反而更明显 - Doctrine 的
second_level_cache默认关闭，但开启后需搭配 Redis/Memcached，否则缓存失效比不缓存还慢
什么时候该放弃 ORM，直接写原生 SQL？
不是“ORM 慢了就换原生”，而是当 SQL 逻辑无法被 ORM 清晰表达时，硬套只会更慢、更难维护。典型信号：
- 一个查询里混用
GROUP BY、窗口函数ROW_NUMBER()、变量计算@rank := @rank + 1—— ORM 往往拆成多步，数据在 PHP 层拼接 - 需要
UNION ALL多个结构不同但结果兼容的子查询，ORM 的 QueryBuilder 支持弱或语法极绕 - 分页用
OFFSET超过 10 万行，ORM 默认不支持游标分页（cursor-based pagination），而原生可轻松改写为WHERE id > ? ORDER BY id LIMIT 20 - PHP 8.5 的
match表达式和只读类对 ORM 映射没帮助，但能让你更安全地封装原生结果集为 DTO
复杂点在于：SQL 写对了只是第一步，后续的参数绑定、类型转换、错误上下文还原，全得自己兜底。很多人低估这部分维护成本，写完三个月就没人敢动那块 SQL 了。
