db2 优化基础 查询运行时间最长的SQL

select elapsed_time_min,appl_status,agent_id from sysibmadm.long_running_sql order by elapsed_time_min desc fetch first 5 rows only

查询运行时间最长的SQL，要使用快照。

首先运行下列语句，打开先关的开关：

db2 UPDATE MONITOR SWITCHES USING lock ondb2 UPDATE MONITOR SWITCHES USING sort ondb2 UPDATE MONITOR SWITCHES USING Bufferpool ondb2 UPDATE MONITOR SWITCHES USING table ondb2 UPDATE MONITOR SWITCHES USING statement ondb2 UPDATE MONITOR SWITCHES USING uow on

然后运行

db2  GET SNAPSHOT FOR DYNAMIC SQL ON easdb >>d:DYNAMICSQL.txt 

在输出的文件里搜索：总计运行时间（秒.毫秒）

比如我使用notepad++，搜索的结果，然后找到相应的SQL，看看能否够改动代码，或者改动SQL

db2 优化基础 查询运行时间最长的SQL

标签：fonts   row   ++   iis   for   content   water   post   notepad   

小编还为您整理了以下内容，可能对您也有帮助：

请教 ：db2数据库 如何查找出执行时间最长的sql？

执行时间最长的20条SQL语句（按时间降序排列），可保存为脚本方便调用：

SELECT rows_read / (num_executions + 1) as avg_rows_read,

rows_written / (num_executions + 1) as avg_rows_written,

stmt_sorts / (num_executions + 1) as avg_sorts,

total_exec_time / (num_executions + 1) as avg_exec_time,

substr(stmt_text,1,1000) as SQL_Stmt

FROM SYSIBMADM.SNAPDYN_SQL ORDER BY avg_exec_time desc fetch first 20 rows only;

祝你学习愉快！

sql查询时间最大的语句

SELECT
*
FROM
表
WHERE
DATE = ( SELECT MAX( DATE ) FROM 表 )

sql查询时间最大的语句

SELECT
*
FROM
表
WHERE
DATE = ( SELECT MAX( DATE ) FROM 表 )

【DB2】SQL优化

于我来说，我喜欢技术，不偏执于某一类开发语言，愿意花时间精力去解决问题。

1.去除在谓词列上编写的任何标量函数

优化前：(耗时3.1s)

优化后：(耗时0.922s)

总结：

DB2可以选择使用START_DATE上的列索引，但是在列上使用了函数后，DB2就无法使用列索引了，从而导致查询效率变低。

2.去除在谓词列上编写的任何数算

优化前：(耗时10.265)

优化后：(耗时3.39s)

总结：

DB2查询时候，会优先选择列CONTRACT_AMT上的索引，如果直接对列CONTRACT_AMT应用数算，DB2就无法使用索引了。一定要做到：列本身(不加数算)放在操作符的一边，而所有的计算都放在另外一边。

3.SQL语句中指定查询列

优化前：(耗时13.15s)

优化后：(耗时2.922s)

总结：

如果Select包含不需要的列，优化工具会选择Indexonly=’N’,这会强制DB2必须进入数据页来得到所请求的特定列，这就要求更多的I/O操作，梁歪，这些多余的列可能是某些排序的部分，这样一来就需要和传递一个更大的排序文件，相应的会使排序成本更高。

4.尽可能不使用distinct

优化前：(耗时0.687s)

优化后：(耗时0.437s)

总结：

在测试distinct与group by性能的过程中，在列CST_ID上添加索引后，发现group by 确实比distinct快一些，但是在数据分布比较离散的情况下使用group by ，比较集中的情况下使用distinct.表数据量较少的情况随便使用哪个都一样， 不管选择谁，都要建立索引

5.Exists、in、not in 、not exists的使用场景选择

5.1 in跟exists的区别：

例如：表A(小表)，表B(大表)

优化前：(耗时1.93s)

优化后：(耗时1.125s)

相反的，

优化前：(耗时1.9s)

优化后：(耗时1.0s)

总结：

in是把外表和内表作hash连接，而exists是对外表作loop循环，每次loop循环再对内表进行查询，一直以来认为exists比in效率高的说法是不准确的。 如果查询的两个表大小相当，那么用in和exists差别不大；如果两个表中一个较小一个较大，则子查询表大的用exists，子查询表小的用in；

简称：子大Exists,子小in

5.2 not in 与 not exists区别：

如果查询语句使用了not in，那么对内外表都进行全表扫描，没有用到索引；而not exists的子查询依然能用到表上的索引。所以无论哪个表大，用not exists都比not in 要快。

6.尽可能使用union all来代替union

优化前：(耗时15.344s)

优化后：(耗时2.719s)

总结：

在union中，DB2最后会自动执行一个排序来消除重复值，这样是很耗费资源的，所以在不需要去重复的情况下，尽可能使用UNION ALL 代替union

N.模板

优化前：(耗时3.1s)

优化后：(耗时0.922s)

总结：

怎么查询oracle中响应时间最长的sql语句,并列出平均响应时间

可以看一下执行计划，里边很详细。在plsql里按住F5即是执行计划。
如果在sql命令窗口：
Explain plan
explain plan for
select * from table_name;
查看结果：
select * from table(dbms_xplan.display());

怎么查询oracle中响应时间最长的sql语句,并列出平均响应时间

可以看一下执行计划，里边很详细。在plsql里按住F5即是执行计划。
如果在sql命令窗口：
Explain plan
explain plan for
select * from table_name;
查看结果：
select * from table(dbms_xplan.display());

一条sql执行过长的时间，你如何优化，从哪些方面？

1、查看sql是否涉及多表的联表或者子查询，如果有，看是否能进行业务拆分，相关字段冗余或者合并成临时表（业务和算法的优化）

2、涉及链表的查询，是否能进行分表查询，单表查询之后的结果进行字段整合

3、如果以上两种都不能操作，非要链表查询，那么考虑对相对应的查询条件做索引。加快查询速度

4、针对数量大的表进行历史表分离（如交易流水表）

5、数据库主从分离，读写分离，降低读写针对同一表同时的压力，至于主从同步，mysql有自带的binlog实现 主从同步

6、explain分析sql语句，查看执行计划，分析索引是否用上，分析扫描行数等等

7、查看mysql执行日志，看看是否有其他方面的问题

个人理解：从根本上来说，查询慢是占用mysql内存比较多，那么可以从这方面去酌手考虑

如何查询sqlserver 超过20秒的sql

其实增加时间字段是最好的选择。
如果这个表不能增加字段，增加后有可能造成前台程序出问题（应该说有这种可能），
那么可以：
给这个表增加一触发器，建立一个新表（该表主键字段,时间字段），
然后再insert触发器中往新表插入一行记录，这样通过 新表与该表进行联合查询，
就能查询出你想要的时间段的数据了。

如何查询sqlserver 超过20秒的sql

其实增加时间字段是最好的选择。
如果这个表不能增加字段，增加后有可能造成前台程序出问题（应该说有这种可能），
那么可以：
给这个表增加一触发器，建立一个新表（该表主键字段,时间字段），
然后再insert触发器中往新表插入一行记录，这样通过 新表与该表进行联合查询，
就能查询出你想要的时间段的数据了。

基于DB2的数据库应用系统的性能优化

　　摘要 结合DB 的使用经验 从数据库设计 查询优化 并发控制 客户/服务器模式四个方面来讨论数据库应用系统性能优化的一些原则 方法等

　　关键词 DB 性能优化 数据库设计 查询优化 并发控制 C/S模式

　　引言

　　DB 是一种高性能的大型关系数据库管理系统 广泛的应用在客户/服务器体系结构中 评价系统性能优化的标准有 吞吐量 响应时间 并行能力等 本文从数据库的设计 查询的优化 并发控制以及客户/服务器模式这四个角度来讨论优化系统性能

　　设计数据库

　　 熟悉业务系统

　　对业务系统的熟悉程度对整个数据库系统的性能有很大影响 一个对业务不熟悉的设计人员 尽管有丰富的数据库知识 也很难设计出性能最佳的数据库应用系统

　　 规范化与非规范化

　　数据库被规范化后 减少了数据冗余 数据量变小 数据行变窄 这样DB 的每一页可以包括更多行 那么每一区里的数据量更多 从而加速表的扫描 改进了单个表的查询性能 但是 当查询涉及多个表的时候 需要用很多连接操作把信息从各个表中组合在一起 导致更高的CPU和I/O花销 那么 有很多时候需要在规范化和非规范化之间保持平衡 用适当的冗余信息来减少系统开销 用空间代价来换取时间代价 有订单信息表OrderDetail 它里面记录了投递员信息 收款员信息 物品信息 价格策略 客户信息… 这些信息分别在投递员信息表 收款员信息表 物品信息表 价格策略表 客户信息表中存放 如果按照规范化的要求 OrderDetail查询时就必须要与这么多个表进行连接或者嵌套查询 如果OrderDetail表中的数据量是在百万级的 那么一次查询所需要的时间可能会达到好几个小时 事实上 只要在设计时保证数据的逻辑有效性 很多信息都可以直接冗余在OrderDetail表中 这些冗余的数据能够极大的提高查询的效率 从而减少CPU和I/O操作

　　 数据条带化

　　如果一个表的记录条数超过一定的规模 那么最基本的查询操作也会受到影响 需要将该表根据日期水平划分 把最近 最经常用的数据和历史的 不经常用的数据划分开来 或是根据地理位置 部门等等进行划分 还有一种划分方式――垂直划分 即把一个属性列很多的表分割成好几个小表 比如把经常用到的属性放在一个表里 不经常用到的属性放在另一个表里 这样可以加快表的扫描 提高效率

　　 选择数据类型

　　对每一属性选择什么样的数据类型很大程度上依据表的要求 但是在不违背表要求的前提下 选择适当的数据类型可以提高系统性能 比如有text列存放一本书的信息 用BLOB而不是character( ) BLOB存放的是指针或者文件参照变量 真正的文本信息可以放在数据库之外 从而减少数据库存储空间 使得程序运行的速度提高 DB 提供了UDT（User Defined Datatypes）功能 用户可以根据自己的需要定义自己的数据类型

　　 选择索引

　　索引是数据库中重要的数据结构 它的根本目的就是为了提高查询效率 现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构 使用索引可以快速 直接 有序的存取数据 索引的建立虽然加快了查询 另一方面却将低了数据更新的速度 因为新数据不仅要增加到表中 也要增加到索引中 另外 索引还需要额外的磁盘空间和维护开销 因此 要合理使用索引

　　●在经常进行连接 但是没有指定为外键的属性列上建立索引

　　●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引 按索引来排序或分组 可以提高效率

　　●在条件表达式中经常用到的不同值较多的列上建立检索 在不同值少的列上不要建立索引

　　●如果待排序的列有多个 可以在这些列上建立复合索引（pound index） 即索引由多个字段复合而成

　　查询优化

　　现在的数据库产品在系统查询优化方面已经做得越来越好 但由于用户提交的SQL语句是系统优化的基础 很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效 因此用户所写语句的优劣至关重要 下面重点说明改善用户查询计划的解决方案

　　 ． 排序

　　在很多时候 应当简化或避免对大型表进行重复的排序 当能够利用索引自动以适当的次序产生输出时 可以避免排序的步骤 当以下的情况发生时 排序就不能省略

　　●索引中不包括一个或几个待排序的列

　　●group by或order by子句中列的次序与索引的次序不一样

　　●排序的列来自不同的表

　　为了避免不必要的排序 就要正确地增建索引 合理地合并数据库表 尽管有时可能影响表的规范化 但相对于效率的提高是值得的 如果排序不可避免 那么应当试图简化它 如缩小排序列的范围等

　　 ． 主键

　　主键用整型会极大的提高查询效率 而字符型的比较开销要比整型的比较开销大很多 用字符型数据作主键会使数据插入 更新与查询的效率降低 数据量小的时候这点降低可能不会被注意 可是当数据量大的时候 小的改进也能够提高系统的响应速度

　　 ． 嵌套查询

　　在SQL语言中 一个查询块可以作为另一个查询块中谓词的一个操作数 因此 SQL查询可以层层嵌套 例如在一个大型分布式数据库系统中 有订单表Order 订单信息表OrderDetail 如果需要两表关联查询

　　 SELECT CreateUser　　FROM Order 　　WHERE OrderNo IN　　(SELECT OrderNo　　FROM OrderDetail 　　WHERE Price= )

　　在这个查询中 找出报纸单价为 元的收订员名单 下层查询返回一组值给上层查询 然后由上层查询块再根据下层块提供的值继续查询 在这种嵌套查询中 对上层查询的每一个值OrderNo 下层查询都要对表OrderDetail进行全部扫描 执行效率显然不会高 在该查询中 有 层嵌套 如果每层都查询 行 那么这个查询就要查询 万行数据 在系统开销中 对表Order的扫描占 ％ 对表OrderDetail的搜索占 ％ 如果我们用连接来代替 即

　 　　　SELECT CreateUser　　FROM Order OrderDetail　　WHERE Order OrderNo=OrderDetail OrderNo AND Praice=

　　那么对表Order的扫描占 ％ 对表OrderDetail的搜索占 ％

　　而且 一个列的标签同时在主查询和where子句中的查询中出现 那么很可能当主查询中的列值改变之后 子查询必须重新查询一次 查询嵌套层次越多 效率越低 因此应当尽量避免子查询 如果子查询不可避免 那么要在子查询中过滤掉尽可能多的行

　　 ． 通配符

　　在SQL语句中 LIKE关键字支持通配符匹配 但这种匹配特别耗费时间 例如 SELECT * FROM Order WHERE CreateUser LIKE M_ _ _ 即使在CreateUser字段上建立了索引 在这种情况下也还是采用顺序扫描的方式 Order表中有 条记录 就需要比较 次 如果把语句改为SELECT * FROM Order WHERE CreateUser > M AND CreateUser < N 在执行查询时就会利用索引来查询 显然会大大提高速度

　　 ． distinct

　　使用distinct是为了保证在结果集中不出现重复值 但是distinct会产生一张工作表 并进行排序来删除重复记录 这会大大增加查询和I/O的操作次数 因此应当避免使用distinct关键字

　　 ． 负逻辑

　　负逻辑如!= <> not in等 都会导致DB 用表扫描来完成查询 当表较大时 会严重影响系统性能 可以用别的操作来代替

　　 ． 临时表

　　使用临时表时数据库会在磁盘中建立相应的数据结构 因为内存的访问速度远远大于外部存储器的访问速度 在复杂查询中使用临时表时 中间结果会被导入到临时表中 这种磁盘操作会大大降低查询效率 另外 在分布式系统中 临时表的使用还会带来多个查询进程之间的同步问题 所以 在进行复杂查询时最好不要使用临时表

　　 ． 存储过程

　　DB 中的Stored Procere Builder可以产生存储过程 运行并测试存储过程 存储过程可以包含巨大而复杂的查询或SQL操作 经过编译后存储在DB 数据库中 用户在多次使用同样的SQL操作时 可以先把这些SQL操作做成存储过程 在需要用到的地方直接引用其名字进行调用 存储过程在第一次执行时建立优化的查询方案 DB 将查询方案保存在高速缓存里 以后调用运行时可以直接从高速缓存执行 省去了优化和编译的阶段 节省了执行时间 从而提高效率和系统利用率

　　最优的查询方案按照某些标准选择往往不可行 要根据实际的要求和具体情况 通过比较进行选择 DB 提供的Query Patroller可以对不同的查询方案的查询代价进行比较 通过追踪查询语句 返回查询不同阶段的系统开销 从而作出最佳选择 DB 提供的Performance Monitor也对整个数据库系统的性能进行监控 包括I/O时间 查询次数 排序时间 同步读写时间等等

　　数据库系统的并发控制也能影响系统性能 多个用户的同时操作可能导致数据的不一致性 DB 为了防止同时修改造成数据丢失和访问未被提交的数据 以及数据的保护读 采用Lock机制来实现控制

Dbeaver查看的sql运行时间?

在dBeaver中，您可以使用以下步骤查询SQL语句的执行时间：

打开dBeaver，连接到您要查询的数据库。

在SQL编辑器中编写您要查询的SQL语句。

右键单击语句并选择“执行语句”。

执行语句后，您将在状态栏中看到执行时间。

如果您想要更详细的执行信息，可以在dBeaver的首选项设置中打开“显示执行计划”，以查看执行计划和其他诊断信息。