定位问题SQL需从执行时间、频率、执行计划等方面判断，通过慢查询日志（如MySQL的slow.log）、性能视图（如performance_schema）、应用日志及APM工具（如SkyWalking）获取并分析SQL，结合执行计划优化，建立监控机制以快速发现和解决性能瓶颈。

当数据库查询出现性能问题或逻辑错误时，定位和获取有问题的SQL语句是优化和修复的关键步骤。直接从应用日志、数据库慢查询日志或监控工具中捕获异常SQL是最常见的方法。

如何判断SQL是否有问题

一个SQL语句是否“有问题”，通常可以从以下几个方面判断：

• 执行时间过长：单次执行耗时明显高于预期，比如超过几秒甚至更久。
• 高频率执行：相同SQL在短时间内被频繁调用，可能造成数据库压力过大。
• 全表扫描：执行计划显示未使用索引，导致扫描大量无关数据。
• 锁等待或死锁：该SQL经常引发锁冲突，影响其他事务执行。
• 返回数据量异常：查询结果过多或过少，不符合业务逻辑。

从慢查询日志中获取问题SQL

MySQL等主流数据库支持开启慢查询日志，用于记录执行时间超过指定阈值的SQL语句。

启用方式示例：

之后可通过以下命令分析日志内容：

通过数据库性能视图定位问题SQL

现代数据库提供动态性能视图，可实时查看正在运行或消耗资源较多的SQL。

例如在MySQL中使用 performance_schema 或 information_schema：

SELECT
DIGEST_TEXT,
COUNT_STAR,
AVG_TIMER_WAIT / 1000000000 AS avg_sec,
SUM_ROWS_EXAMINED,
SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
WHERE AVG_TIMER_WAIT > 1000000000000 -- 大于1秒
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 10;

这条查询能列出平均执行时间最长的SQL模板，帮助快速识别性能瓶颈。

应用层日志与APM工具辅助排查

很多应用框架（如Spring Boot、Django）支持SQL日志输出。开启后可在控制台或日志文件中直接看到执行的SQL语句。

建议配置：

• 打印SQL语句及其参数
• 记录执行耗时
• 结合唯一请求ID，便于追踪完整调用链

使用APM工具（如SkyWalking、Prometheus + Grafana、New Relic）可以可视化SQL性能指标，自动告警异常语句。

基本上就这些。关键是建立监控机制，在问题发生时能快速提取SQL并分析执行计划。不复杂但容易忽略。