精准捕获慢查询与异常SQL并快速定位根因，需分层启用Doctrine+MySQL日志、结构化记录，并结合Profiler实时比对：一、用Profiler筛查耗时>50ms查询及N+1问题；二、实现SQLLogger记录上下文与调用栈；三、MySQL层设slow_query_log=ON并查slow_log表；四、监听onException事件捕获错误SQL并分类告警。
在 Symfony2 项目中开启数据库查询日志，核心目标不是“看到所有 SQL”，而是**精准捕获慢查询与异常 SQL，并快速定位根因**。靠盲目开启 MySQL 通用日志或堆砌日志行数只会淹没关键信息。真正高效的调试路径是：分层启用（Doctrine 层 + MySQL 层）、结构化记录、结合 Profiler 实时比对。
一、优先用 Symfony Profiler 快速筛查问题SQL
这是开发阶段最轻量、最直接的入口——无需改配置，打开页面底部工具栏就能获得可操作线索：
- 点开 “Doctrine” 标签页，按执行耗时倒序排列，一眼识别单次 >50ms 的查询；重点关注重复出现相同 WHERE 条件的 SELECT，大概率是 N+1 问题
- 看 “SQL 查询次数” 总数：>10 次需立即检查控制器或 Repository 是否循环调用 find()；若某接口稳定在 30+ 次，基本可判定存在未合并的关联加载
- 点击具体查询，查看生成的完整 SQL 和参数绑定值，确认是否意外触发全表扫描（如缺少 WHERE 或索引字段未被使用）
二、启用 Doctrine 查询日志并绑定上下文
Profiler 只展示已执行的语句，无法捕获失败前的异常尝试或超时中断。需在应用层主动增强日志语义：
- 实现 SQLLogger 接口，在
startQuery()记录开始时间、SQL 原文、参数；在stopQuery()计算耗时，若超过阈值（如 200ms）则写入独立日志文件或通道，并附加当前路由、用户 ID、请求 ID - 避免只记 SQL 字符串：将
$e->getTraceAsString()截取前 3 层调用栈（如 UserController→ProductRepository→findActive()），方便回溯到业务代码行 - 不建议全局开启详细日志：仅在 debug 环境或特定命令行任务（如数据迁移）中激活，生产环境应关闭或仅记录异常/超时事件
三、MySQL 层配合开启慢查询日志（精准定位）
当 Profiler 和 Doctrine 日志仍无法复现问题（例如偶发超时、线上环境），必须下沉到数据库层验证：
- 登录 MySQL 执行：
SHOW VARIABLES LIKE 'slow_query_log';确认状态；若为 OFF，临时启用：SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; - 推荐日志输出设为 TABLE：
SET GLOBAL log_output = 'TABLE';，之后直接查mysql.slow_log表，支持 SQL 过滤与排序，比解析文本日志更可靠 - 注意两个易忽略点：一是
log_queries_not_using_indexes = ON会大量刷日志，仅排查索引缺失时临时开启；二是修改后需实际触发一条慢 SQL（如SELECT SLEEP(2);）验证日志是否真实写入，不能只看配置生效
四、错误SQL的即时捕获与告警
慢查询影响体验，而语法错误、死锁、连接超时等会直接导致功能失败。这类问题必须秒级感知：
- 监听 Doctrine 的
onException事件，在异常抛出前捕获 SQL、参数、错误码（如 1064 语法错、1205 死锁）、堆栈，并写入结构化日志（JSON 格式） - 对
PDOException做分类处理：连接类错误（SQLSTATE HY000）触发邮件告警；语法类（42000）自动提交到内部 issue 系统并关联 Git 提交记录 - 避免在 catch 块中只写
echo $e->getMessage()：必须保留原始 SQL 和绑定参数，否则无法区分是 “WHERE id = ?” 还是 “WHERE id = :id” 导致的占位符错误
