定位问题SQL需从执行时间、频率、执行计划等方面判断，通过慢查询日志（如MySQL的slow.log）、性能视图（如performance_schema）、应用日志及APM工具（如SkyWalking）获取并分析SQL，结合执行计划优化，建立监控机制以快速发现和解决性能瓶颈。
当数据库查询出现性能问题或逻辑错误时，定位和获取有问题的SQL语句是优化和修复的关键步骤。直接从应用日志、数据库慢查询日志或监控工具中捕获异常SQL是最常见的方法。
如何判断SQL是否有问题
一个SQL语句是否“有问题”，通常可以从以下几个方面判断：
- 执行时间过长：单次执行耗时明显高于预期，比如超过几秒甚至更久。
- 高频率执行：相同SQL在短时间内被频繁调用，可能造成数据库压力过大。
- 全表扫描：执行计划显示未使用索引，导致扫描大量无关数据。
- 锁等待或死锁：该SQL经常引发锁冲突，影响其他事务执行。
- 返回数据量异常：查询结果过多或过少，不符合业务逻辑。
从慢查询日志中获取问题SQL
MySQL等主流数据库支持开启慢查询日志，用于记录执行时间超过指定阈值的SQL语句。
启用方式示例：
SET GLOBAL slow_query_log = 'ON';SET GLOBAL long_query_time = 1;
SET GLOBAL log_output = 'FILE';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
之后可通过以下命令分析日志内容：
mysqldumpslow -s c -t 10 /var/log/mysql/slow.log# 按调用次数排序，显示前10条最常出现的慢SQL
通过数据库性能视图定位问题SQL
现代数据库提供动态性能视图，可实时查看正在运行或消耗资源较多的SQL。
例如在MySQL中使用 performance_schema 或 information_schema：
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并分析执行计划。不复杂但容易忽略。
