作为常年跟DB2打交道的DBA，不管是日常遇到慢查询排查，还是面试被问到这类问题，我都是按「定位-分析-排查-优化-验证」的流程来处理，下面把具体思路和命令拆解清楚：

一、先定位：找到耗时过长的查询 #

首先得精准定位到到底是哪条SQL在拖后腿，常用的方法有：

• 实时监控：用db2top工具（交互式界面，输入d切换到动态SQL视图，能看到当前运行SQL的执行时间、CPU占比等），或者用命令行工具db2pd -d <你的数据库名> -dynamic，直接列出当前活跃的动态SQL，重点看EXEC_TIME列。
• 历史慢查询：查询系统视图SYSIBMADM.LONG_RUNNING_SQL，这个视图会记录执行时间超过阈值的SQL，比如：

  SELECT SUBSTR(STMT_TEXT, 1, 200) AS SQL_TEXT, EXEC_TIME_MS, NUM_EXECUTIONS 
  FROM SYSIBMADM.LONG_RUNNING_SQL 
  ORDER BY EXEC_TIME_MS DESC;
  

• 快照获取：用db2 get snapshot for dynamic sql on <数据库名>，能拿到更详细的SQL执行统计，比如逻辑读、物理读的次数。

二、再分析：看执行计划找问题根源 #

定位到SQL后，必须看它的执行计划，这是优化的核心：

• 生成执行计划：用EXPLAIN命令生成计划数据，比如：

  EXPLAIN PLAN FOR <你的慢SQL语句>;
  

• 格式化查看计划：用db2exfmt工具生成易读的格式化报告，命令如下：

  db2exfmt -d <数据库名> -g TIC -w -1 -n % -s % -o slow_sql_explain.txt
  

  打开报告重点看这几个点：有没有出现TABLE SCAN（全表扫描，说明可能缺索引）、索引是否被正确使用、连接方式是否合理（比如大表用哈希连接比嵌套循环更高效）、排序操作是否过多（可能需要调大排序堆）。

三、排查瓶颈：系统资源与锁等待 #

有时候慢查询不是SQL本身的问题，而是系统资源或锁冲突导致的：

• 资源监控：用db2pd -osinfo查看系统CPU、内存、磁盘IO的负载；用db2pd -bufferpools看缓冲池命中率，如果命中率低于95%，说明缓冲池不够大，需要调整。
• 锁冲突排查：用db2pd -locks查看当前锁持有和等待情况，或者db2 get snapshot for locks on <数据库名>，如果发现有长时间的锁等待，要找到对应的事务和SQL，判断是锁粒度太大还是事务未及时提交。

四、优化操作：从SQL、对象到配置 #

根据分析结果，针对性优化：

1. SQL语句优化：
   • 避免SELECT *，只查询需要的列，尽量用覆盖索引；
   • 不要在WHERE子句的列上用函数（比如DATE(create_time) = '2024-05-01'），改成范围查询create_time BETWEEN '2024-05-01 00:00:00' AND '2024-05-01 23:59:59'，这样能用到索引；
   • 减少嵌套子查询，用JOIN替代，尤其是大表关联时。
2. 对象优化：
   • 缺失索引的话，创建合适的索引：CREATE INDEX idx_table_col ON <表名>(<列名1>, <列名2>);（注意不要创建过多索引，会影响写入性能）；
   • 更新统计信息：如果优化器用的是过期的统计信息，会生成差的执行计划，执行RUNSTATS ON TABLE <表名> WITH DISTRIBUTION AND INDEXES ALL来更新。
3. 数据库配置调整：
   • 调整缓冲池大小：ALTER BUFFERPOOL IBMDEFAULTBP SIZE <新的大小> IMMEDIATE;；
   • 调大排序堆：db2 update db cfg for <数据库名> using SORTHEAP 4096;（根据内存情况调整，太大可能导致内存溢出）；
   • 调整锁超时：如果是锁等待导致的慢查询，可适当调大LOCKTIMEOUT参数：db2 update db cfg for <数据库名> using LOCKTIMEOUT 30;（单位秒）。

五、验证优化效果 #

优化后，重新执行SQL，用db2 get snapshot for dynamic sql对比执行时间、逻辑读、物理读的变化，或者用db2top监控，确认性能提升。

内容的提问来源于stack exchange，提问作者Monish Patil