直接回答：三管齐下：数据库侧开慢查询日志（MySQL 的 slow_query_log + long_query_time，PostgreSQL 的 log_min_duration_statement）；用 pt-query-digest 或 pg_stat_statements 聚合分析，按总耗时排序找出 Top SQL；应用侧通过 APM（SkyWalking、Pinpoint）或 ORM SQL 日志定位慢查询对应的业务入口。

展开解析：排查步骤建议：

  1. 慢日志阈值先设宽松（如 1s），逐步收紧，注意开日志本身有少量开销。
  2. 聚合工具按"指纹"归并同类 SQL，关注总耗时、平均耗时、扫描行数/返回行数比——扫描多返回少通常缺索引。
  3. 对 Top SQL 用 EXPLAIN 看执行计划：是否全表扫描、索引选择、临时表与文件排序。
  4. 区分"偶发慢"与"持续慢"：偶发可能是锁等待、缓冲池冷、并发高峰，需结合 SHOW PROCESSLIST / pg_stat_activity 看当时状态。

追问方向：如何分析锁等待导致的慢（performance_schema、innodb status）、如何建立慢查询常态化监控。