分享DB2 SQL查询性能问题一例
同事在测试服务器上遇到了一个严重的performance问题,请我帮忙(本人非专业DBA,只是相比同事多干了两年罢了)看看SQL调优和加index
此SQL是一个较复杂的查询,inner join/left join了多个表,其中有几个表的数据量都在百万级以上。
我拿到手并没多想,先看了SQL结构,没什么大问题。然后就跑了db2expln和db2advis,db2expln 也是显示每个表都走index了,没有扫表的
#### db2advis
Recommending indexes...
total disk space needed for initial set [ 682.400] MB
total disk space constrained to [69886.654] MB
Trying variations of the solution set.
Optimization finished.9 indexes in current solution
[12511.0449] timerons (without recommendations)
[6372.6714] timerons (with current solution)
[49.06%] improvement
一看这不显然Index不足或者有问题嘛,那就按着建议的Index和存在的Index对照着来尝试喽。
试了多个Index后发现最多才5%的提升,很郁闷。但加到一个表的索引后发现timerons突然反而升高了..而且我加的新索引并未被使用..
Recommending indexes...
total disk space needed for initial set [ 660.656] MB
total disk space constrained to [69886.654] MB
Trying variations of the solution set.
Optimization finished.9 indexes in current solution[22776.0215] timerons (without recommendations)[22370.5879] timerons (with current solution)[1.78%] improvement
另:db2expln多了些不同的信息
Left Outer Nested Loop Join
| Piped Inner
| Access Table Name = XXXXXX ID = 599,4
| | Index Scan: Name = YYYYYY ID = 3
| | | Regular Index (Not Clustered)
| | | Index Columns:
| | | | 1: DELETED (Ascending)
| | | | 2: OPPORTUNITY_ID (Ascending)
| | | | 3: ASSIGNED_USER_ID (Ascending)
| | | | 4: TYPE (Ascending)
| | #Columns = 0
| | Compressed Table
| | #Key Columns = 2
| | | Start Key: Inclusive Value
| | | | 1: ?
| | | | 2: ?
| | | Stop Key: Inclusive Value
| | | | 1: ?
| | | | 2: ?
| | Index-Only Access
| | Index Prefetch: Sequential(99), Readahead
| | Isolation Level: Uncommitted Read
| | Lock Intents
| | | Table: Intent None
| | | Row : None
| | Sargable Index Predicate(s)
| | | #Predicates = 1
| | | Insert Into Integer Sorted Temp Table ID = t2
| | | | #Columns = 1
| | | | #Sort Key Columns = 1
| | | | | Key 1: (Ascending)
| | | | Sortheap Allocation Parameters:
| | | | | #Rows = 28490.000000
| | | | | Row Width = 20
| | | | Duplicate Elimination
| Integer Sorted Temp Table Completion ID = t2
| List Prefetch Preparation
| | Access Table Name = XXXXXX ID = 599,4
| | | #Columns = 1
| | | Compressed Table
| | | RID List Fetch Scan
| | | Fetch Using Prefetched List
| | | | Prefetch: 105 Pages
| | | Isolation Level: Uncommitted Read
| | | Lock Intents
| | | | Table: Intent None
| | | | Row : None
| | | Sargable Predicate(s)
| | | | #Predicates = 3
优化器查找和使用索引受到了新Index的影响以致影响了性能。
查一下索引统计信息:
select substr(INDNAME,1,25) as INDNAME, FULLKEYCARD
from syscat.indexes
where tabname='XXXXXX' and tabschema='SCTID'# INDNAME FULLKEYCARD
1 YYYYYY -1
2 SSSSSS -1
3 XXXXXX(NEW) 3,844,196
4 ZZZZZZ -1
说明是统计信息有问题才导致的查询性能问题..
在表上执行了RUNSTATS with indexes all后:
# INDNAME FULLKEYCARD
1 YYYYYY 4,985,715
2 YYYYYY 4,985,715
3 YYYYYY 3,844,196
4 YYYYYY 4,684,818
再次执行db2avis
Recommending indexes...
total disk space needed for initial set [ 802.328] MB
total disk space constrained to [69986.213] MB
Trying variations of the solution set.
A better solution was found. Continuing search.
Optimization finished.10 indexes in current solution
[5586.8818] timerons (without recommendations)
[5165.5610] timerons (with current solution)
[7.54%] improvement
得到这个结果后询问同事,原来他们前两天刚做过数据移植,这个表的数据量差不多翻了一倍..但是之后应该是没做过RUNSTATS或者reorg,重启之类的操作..
好吧,这次得到的经验教训就是下次遇到SQL性能问题,先查看表的统计信息是否正确再研究如何优化索引,不能一发现查询慢就先考虑优化索引。人还是要多读书..
希望本文能起到点抛砖引玉的作用吧。
参考:
低基数索引为什么会对性能产生负面影响
分享DB2 SQL查询性能问题一例相关推荐
- SQL Server-聚焦sp_executesql执行动态SQL查询性能真的比exec好?
前言 之前我们已经讨论过动态SQL查询呢?这里为何再来探讨一番呢?因为其中还是存在一定问题,如标题所言,很多面试题也好或者有些博客也好都在说在执行动态SQL查询时sp_executesql的性能比ex ...
- 五个 SQL 查询性能测试题,只有 40% 及格率,你敢来挑战吗?
作者 | 董旭阳TonyDong,CSDN 博客专家 责编 | 唐小引 头图 | CSDN 下载自东方 IC 出品 | CSDN 博客 下面是 5 个关于索引和 SQL 查询性能的测试题:其中 4 个 ...
- LINQ – 使用DataLoadOptions 提高LINQ to SQL 查询性能
LINQ – 使用DataLoadOptions 提高LINQ to SQL 查询性能 EntLib.com开源小组发表,http://www.EntLib.com,2008-7-2 LINQ to ...
- oracle function 写查询语句_五个 SQL 查询性能测试题,只有 40% 及格率,你敢来挑战吗?...
作者 | 董旭阳TonyDong,CSDN 博客专家 责编 | 唐小引 头图 | CSDN 下载自东方 IC 出品 | CSDN 博客 下面是 5 个关于索引和 SQL 查询性能的测试题:其中 4 个 ...
- t–sql pl–sql_糟糕SQL查询设计– SQL查询性能的杀手–基本知识
t–sql pl–sql Depending on the performance problem cause, fixing poor SQL query design can be quick o ...
- 预编译sql查询语句_频繁查询重新编译– SQL查询性能杀手–检测
预编译sql查询语句 previous part of this article, we presented query recompilation basics. We explained when ...
- execution 排除_使用SQL Server 2016 Live Execution统计信息对SQL查询性能进行故障排除
execution 排除 SQL Server Management Studio a graphical interactive that allows you to interact with t ...
- 五个 SQL 查询性能测试题,只有 40% 及格率,你敢来挑战吗?| 原力计划
作者 | 董旭阳TonyDong,CSDN 博客专家 责编 | 唐小引 头图 | CSDN 下载自东方 IC 出品 | CSDN 博客 下面是 5 个关于索引和 SQL 查询性能的测试题:其中 4 个 ...
- mysql及格率70以上_五个 SQL 查询性能测试题,只有 40% 及格率,你敢来挑战吗?| 原力计划...
作者 | 董旭阳TonyDong,CSDN 博客专家 责编 | 唐小引 头图 | CSDN 下载自东方 IC 出品 | CSDN 博客 下面是 5 个关于索引和 SQL 查询性能的测试题:其中 4 个 ...
最新文章
- 2ASK和2FSK相干解调误码率仿真matlab
- hudson linux节点,Linux 环境下搭建 Jenkins(Hudson)平台
- python爬虫怎么爬小说_python从爬虫基础到爬取网络小说实例
- 简单文件系统的实现_300来行代码带你实现一个能跑的最小Linux文件系统
- PHP的require与include
- python数据库更新消息提醒_用Python实现校园通知更新提醒功能
- linux基础命令rpm,rpm常用命令集合1
- android 人体部位点击,用 TensorFlow Lite 在安卓系统上实时人体姿态跟踪
- 迎亚运 广州推出全国首个地铁导向地图
- 定时器的用法以及pwm的调速
- 常见通信协议与通讯协议梳理- 通讯协议
- 不用光盘和u盘怎么重装系统win10
- windows进程管理器_探究 Process Explorer 进程树选项灰色问题
- Codeforces Round #784 (Div. 4)#蒻枸题解
- (图解)设置封面中的下划线一样长
- 【Unity】Unity中获得碰撞体碰撞的位置
- GAN(生成对抗网络) 解释
- Python 卡尔曼滤波器实现
- TypeError: ToTensor() takes no arguments报错显示
- Illustrator教程之 在 Ai 2022中创建一个新文档
热门文章
- 怎么从小事中看“思维突破”
- Python模块介绍(如何安装、使用)
- 【TFS-CLUB社区 第7期赠书活动】〖从零开始利用Excel与Python进行数据分析 自动化办公实战宝典〗等你来拿,参与评论,即可有机获得
- 附近商家位置java开发附近定位
- 通往Android的神奇之旅-刘桂林-专题视频课程
- 投入linux怀抱,拜拜win
- Tuxera NTFS21Mac苹果电脑读取硬盘磁盘软件
- Clickhouse—时间窗口函数
- ubuntu 8.04 中文输入法 中文撑持
- 菜鸡做题·20200418会员登陆页面(CTF)