Profiler看不到SQL执行时间需先确认debug模式开启且doctrine.dbal.logging=true或doctrine.orm.debug=true；SQL面板默认不按耗时排序，需点击Time列手动排序；EXPLAIN结果可能失真，应结合SHOW PROFILE和slow_query_log交叉验证。
Profiler里看不到SQL执行时间？先确认是否启用了数据收集
默认情况下，Symfony的DoctrineDataCollector只在debug模式下启用，且要求doctrine.dbal.logging为true（或doctrine.orm.debug开启），否则SQL语句和耗时根本不会进Profiler。
- 检查
config/packages/dev/doctrine.yaml中是否包含logging: true（DBAL层）或debug: true（ORM层） - 确保环境是
dev且APP_DEBUG=1，生产环境即使配置了也不会收集 - 如果用了
doctrine.dbal.driver: pdo_mysql但没配options: { 1002: "SET NAMES utf8mb4" }之类自定义选项，某些旧版驱动可能跳过日志钩子——换用pdo_mysql显式声明可规避
点开SQL tab却只有“Executed 12 queries”，没看到具体慢在哪？
Profiler的SQL面板默认按执行顺序排列，不自动排序耗时。真正拖慢页面的查询往往藏在中间或末尾，靠肉眼扫很容易漏掉。
- 点击表头
Time列进行升序/降序排序，重点关注耗时 >50ms 的SELECT或带JOIN/ORDER BY的语句 - 注意看
Parameters列：如果同一SQL反复出现、仅id参数不同，大概率是N+1问题，不是单条慢，而是量大累积 - 点开某条SQL右侧的
Explain按钮（需MySQL支持），它调用的是EXPLAIN SELECT ...，但注意：如果原SQL含PARAMETER占位符，Profiler传给EXPLAIN的是空值或默认值，结果可能失真
为什么doctrine:query:sql命令查不到慢查询？
doctrine:query:sql只是执行SQL并输出结果，它不经过Doctrine的事件监听器链，也不触发DebugStack记录——换句话说，它完全绕过了Profiler的数据采集路径。
- 想复现慢查询，应该用
php bin/console doctrine:query:dql "SELECT u FROM App\Entity\User u WHERE u.status = :status"配合--env=dev，这样才走ORM完整流程 - 直接执行原生SQL请改用
php bin/console dbal:run-sql "SELECT ..."（Symfony 5.4+），它至少会走DBAL连接层，部分版本能触发日志 - 更可靠的方式是结合
slow_query_log：在MySQL配置中打开slow_query_log=ON和long_query_time=0.1，再查mysql.slow_log表，和Profiler交叉验证
Profiler显示某查询耗时800ms，但EXPLAIN说type=ALL只扫描12行？
这是典型「执行计划失真」：Profiler里的EXPLAIN是静态分析，不反映真实执行时的锁等待、缓冲区缺失、临时表磁盘写入等开销。
- 立刻去MySQL终端执行
SHOW PROFILE FOR QUERY <query_id>;</query_id>（需profiling=ON），它能分阶段显示CPU、block io、context switch耗时 - 检查是否有
Using temporary或Using filesort——哪怕行数少，只要触发磁盘临时表，IO延迟就上来了 - 注意时区差异：
datetime字段用WHERE created_at > '2024-01-01'但PHP传的是UTC时间，而MySQL时区是CST，可能导致索引失效，EXPLAIN仍走索引但实际全表扫描
慢查询从来不在单个数字里，而在参数绑定方式、连接复用状态、甚至APCu缓存是否命中这些链路细节上。Profiler只是入口，别让它替你做判断。
