db2数据库性能

⑴ 【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)

总结：

⑵ 在数据库设计过程中要注意哪些问题

DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少，不复杂，那么就算不怎么规划，也能够达到比较高的性能。如果对象数据比较多、比较大的话，那么就需要在数据库设计之前好好的规划，否则会在很大程度上影响数据库的性能与稳定性。

一、选择合适的语言与数据库字符集。

在企业中部署数据库的时候，首先需要在操作系统上安装数据库。而在安装数据库的时候，需要选择安装的语言环境。即是以中文状态下安装数据库还是以英文状态安装数据库。如在启动安装程序的时，可以利用/i language选项来指定安装过程中所采用的语言。到目前为止，DB2数据库已经支持很多种语言。那么数据库在安装过程中，该采用什么语言呢？笔者建议，只要数据库管理员有一点英语基础，最好能够采用英文语言环境来进行安装。虽然说现在DB2数据库的中文语言环境已经设计的比较完善，但是笔者仍然担心其有一些不知名的漏洞。为此笔者在安装DB2数据库的时候，基本上都采用的是英文语言环境来进行安装。即将语言设置为“EN”，表示英文。提高DB2数据备份与恢复的效率。

另外如果DB2 数据库中要保存英文以外的数据，或者说用户会使用不同的字符集访问数据库时，还需要在数据库安装过程中选择特定的数据库字符集。DB2数据库中的所有字符数据，包括数据字典中的数据，都是存储在数据库字符集中的。如果用户使用不同的字符集访问数据库时，数据库管理员就需要选择包含所有这些用户的字符集的超集。只有如此，才能够确保系统能够很方便的使用替代字符完成字符的转换，从而提高数据库的性能。如果用户选择的字符集不对，有可能会出现一些莫名其妙的问题。如一次用户在安装数据库过程中，没有选择合适的字符集。虽然在使用的过程中，其存储中文字符没有问题。但是当对数据库采取还原操作时，却发现还原后的数据库中有些原来是中文字符的地方，尽然出现了乱码。这主要就是没有选择合适的字符集惹的祸。有时候如果字符集选择不当的话，从外部数据源(如Excel表格)导入数据的时候，中文数据也会无法顺利导入。所以，数据库管理员在安装数据库的时候，需要根据实际企业，来选择合适的字符集。

二、评估数据库对象的大小、数量。

DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少，不复杂，那么就算不怎么规划，也能够达到比较高的性能。如果对象数据比较多、比较大的话，那么就需要在数据库设计之前好好的规划，否则会在很大程度上影响数据库的性能与稳定性。其实DB2 数据库就好像一个仓库，数据库中的对象(如索引、数据表、表空间)等等就好像仓库中的货物。如果货物比较少，那么随便放放，仓库都显得很空旷。货物寻找起来也会很方便。但是如果货物数量比较多、比较大，就必须要对其存储空间进行合理规划。只有如此才能够让仓库的空间利用率达到最佳状态。并且货物的存放有序，在查找起来也特别的方便。笔者这里就以仓库管理为例，说话该如何做好数据库对象大小、数量等方便的评估，以及他们对于数据库性能与稳定性的影响。

1、根据对象大小来规划存储空间。在仓库货物的摆放上，要根据货物的大小来规划存储空间。或者说要首先防止大的货物。只有如此空间的利用率才会最高。其实在规划DB2对象的时候，也是如此。如某些表可能会包含的记录比较多，属于大表。此时数据库管理员就需要考虑，是否将其放置在一个独立的表空间或者硬盘空间上，以提高数据操作的性能。大表所对应的索引往往也是比较大的。为此在硬件条件允许的情况下，将索引表与数据表分别存放在不同的硬盘上，可以提高数据库的性能。而对于一些比较小的对象(如数据表)，可以将它们存放在一个表空间中。其实这个表空间就好像仓库中的一个个纸盒子。将小的对象放入到这个“纸盒子”中，不但不占空间，而且也容易管理。

2、根据对象的使用频率来规划存放空间。在仓库中摆放物品的时候，往往会把近期就要用到的货物或者频繁需要用到的东西放在仓库门口或者容易拿到的地方。如此在拿这些货物时就会比较便捷，也不会对其他货物产生影响。对于DB2数据库中的对象来说，也是这么一回事。可以将那些访问量比较大的对象，如索引、数据表，存放在性能比较好的硬盘上或者单独的硬盘中。此时访问这些数据，就不会与其它对象产生I/O冲突，操作起来速度就会比较快。而将不怎么用到的对象，存放在一起。由于他们不怎么被用到，所以即使存放在性能比较低的硬盘上，其对数据库性能产生的负面影响也是非常有限的。 在DB2数据库里面如何更新执行计划

3、根据类别来存放数据库对象。在仓库中存放货物的时候，还会对其进行分类。然后根据类别来进行存放。这有利于货物的管理与检索。其实在数据库对象存储空间设计时，也需要考虑这个因素。如现在应用软件在设计的时候，很多都是根据模块来设计。那么在数据库对象设计时，也需要根据这个模块来设计存储的空间。如将同一个模块的数据库对象存放在同一个表空间内。不过这可能会跟上面的两个建立相违背。此时最好是在对象的命名上做文章。如可以根据模块的不同，分别给数据库对象取一个相同的前缀或者后缀。如即使同一块模块要用到多个表空间，此时就可以给表空间一个相同的前缀。如此在管理数据库对象的时候，根据表空间的前缀就可以判断其所属的模块了。如果再加上一个后缀来表示其数据库对象的分类，那么就更合理了。为此在管理数据库对象的时候，要执行分类管理。不仅要从技术上对其进行分类，如分为索引、数据表、关键字等等。还需要从功能上进行分类，如按应用程序的模块来进行分类等等。

三、设计好数据库备份与还原的方案。

在数据库交付生产使用之后，往往需要进行大量的测试。但是在测试过程中往往又会产生很多的垃圾数据。可是交给企业应用的，肯定是一个干净的数据库系统。为此在数据库设计的时候，就需要想好如果减少测试过程中的垃圾数据。或者采取什么样的方式来实现在交互时自动清除垃圾数据的机制。

一般来说，想要一个数据库备份与还原的方案，减少数据库测试所产生的垃圾数据。如现在在给企业部署数据库的时候，往往是先安装一个干净的数据库系统。当然字符集这些需要预先设置好。然后再利用数据库还原功能将预先定义好的数据库模型还原出来。

另外有些时候需要两个方案互为补充。如在数据库初始化的过程中，采用数据库还原的方式来创建数据库对象。但是在应用软件升级的时候，由于此时已经有了用户的数据，为此不能够在使用数据库还原的方法。而是通过应用程序来执行某些SQL代码，来调整或者增加部分数据库对象。无论采用哪一种方式，需要遵循的一个原则就是在给企业创建数据库对象时要最大限度的减少测试。而要做到这一点，就是需要先在测试服务器上创建对象并测试对象可用。然后直接将相关的SQL代码在投入使用的数据库服务器上执行。

⑶ sqlserver和DB2的区别

主要区别在于数据库性能
SQL Server 属于中型数据库，主要应用于一般商用环境，处理百万到千万级数据量是没有问题的，而DB2属于大型数据库，主要用于电信级或者数据中心级应用，可处理亿级以上数据量。
另外SQL Server 只能运行在Windows 环境下，而DB2主要运行在UNIX或Linux环境下，因此 DB2性能总体优于SQL Server。

⑷ 怎么用loadrunner 压测 DB2数据库服务器性能

这个需要写代码
大致是：首先定义数据库的用户名、密码、数据库名
然后连接JDBC数据库，写个if语句判断
测试你的SQL语句
最后清理缓存

⑸ DB2与SQL Server的区别

一、适用平台上的差异。
到目前为止，微软的SQL Server数据据库只支持微软的操作系统。而DB2 数据库不仅支持Windows操作系统，而且还支持Linux等开源操作系统。也就是说，DB2具有很好的跨平台性能。现在很多企业中，都是以Linux或者Unix操作系统作为数据库服务器的。这主要是因为从安全性和稳定性上面Linux或者Unix操作系统都要比Windows操作系统略胜一筹。所以从这一点来说，DB2 数据库就要比SQLServer数据库的应用面要广。
二、安全性上的差异。
对于数据库来说，特别是那些相互联网用户开发的数据库系统，安全性一直是左右数据库选型的主要因素。而在这个安全性上面，SQLServer数据库与DB2数据库之间有很大的差异。据笔者所知，SQLServer数据库到目前为止，没有取得任何国际上认可的安全证书。而对于DB2数据库来说，其已经获得了国际上最高级别的ISO标准认证。，虽然说证书不能够说明问题，但是至少说明DB2 数据库的安全性也是有所保障的。微软在SQLServer数据库上安全投入的不足，让其无法适应互联网安全的威胁。为此这也让SQLServer数据库少了很多订单。
三、数据处理上的差异。
在数据处理的能力上，SQLServer数据库与DB2数据库也有很大的差异。SQLServer数据库虽然支持多用户，但是在大量并发访问的情况下，性能会显着下降。而DB2 数据库可以说是专门为处理大量的并发访问所涉及的。在数据处理上，如果并发行访问比较少或者数据量并不是很大，那么DB2数据库与SQLServer数据库相比，并不会有很大的优势。甚至可能还是SQLServer数据库的性能比较好。但是如果涉及到海量数据的处理，如数据仓库或者企业级的应用，那么DB2数据库的性能就要远远超过SQLServer数据库。从这一点上来说，DB2 数据库适合一些企业级的应用，而SQLServer数据库则因为价格相对便宜、维护相对简单，而比较适合中小企业使用。
四、在投资成本上的差异。
企业部署数据库应用时，所耗费的成本主要有三块，分别为硬件上的投资、数据库授权与人员的支出。在硬件上的投资，两个数据库没有多大的差异。但是在数据库的授权成本与人员的支出上，却有很大的差异。从数据库的授权成本上看，DB2 数据库要比SQLServer数据库高的多。从人员的支出看，企业招募一个DB2 数据库管理员要比招募一个SQLServer数据库管理员贵的多。这主要是因为DB2数据库管理员比较少，而且其往往需要同时维护多个分支机构的应用。所以DB2数据库管理员的价格就要比SQLServer的价格贵好几倍。所以说，从整体成本来看，企业部署DB2数据库要比采用SQLServer数据库贵许多。
可见DB2与SQLServer数据库各有优劣。企业需要根据自己的规模、对于安全性的考虑、性能上的要求以及可以接受的成本等多方面来进行权衡，才能够选择一个合适自己的数据库系统。

⑹ 数据库在金融行业中的应用

DB2数据库为何在金融领域应用如此广泛？在我接触过的银行用户中，绝大部分都在使用IBM DB2数据库产品，当然还是有一大批证劵公司也在使用。给我印象最为深刻的一次是在深圳办的一场DB2技术专家沙龙，那次来的基本上都银行用户和证劵用户。当时，就在想，DB2数据库产品在金融领域应用咋那么广呢？

在开始这个讨论之前，我也问了一些朋友，问他们是什么原因导致了这一事实的发生，其中有人回答是历史原因，也有人回答是因为DB2数据库产品好。当然，众多金融客户选择DB2数据库产品，肯定是有各自的原因，历史原因也罢，功能强大、性能稳定也罢，肯定各有说词。不过我们可以想象一下，对于金融用户来说，每天所产生的数据都非常多，且复杂，而且这些数据都相当重要，来不到半点马虎。因此，他们在选择数据库产品的时候，自然是分外小心，不敢怠慢。另外，作为一家金融企业，在IT上的预算肯定也比较充足，所以产品的价格自然不是他们担心的问题（当然，这只是一种猜测！）。这样再分析原因的时候，我们就把重点放在了DB2数据库的性能和稳定性上。那么，究竟是不是了DB2数据库的性能和稳定性导致了它在金融领域的应用如此广泛呢，我不得而知！

针对这个‘DB2数据库为何在金融领域应用如此广泛？’的疑问，是一个值得我们思索的过程。但至于是什么真正的原因导致的，我这主题中就不详细聊了，因为我的答案都是来源于大家，只有有了大家的支持，这个答案才会日渐丰富，日渐完善。

DB2的并发性、稳定性、扩展性这些都做得不错，
金融行业很多业务是实时性交易很强的系统它们追求的是系统的稳定性，性能好，支持高并发、安全性高
所以选择ORACLE、DB2这类数据库等等
主要是用DB2 在用AIX系统 本身兼容性又好吧这样稳定性更强，而且DB2 刚开始打开市场时是免费使用的

在金融行业，大家知道数据量大，数据复杂，更新频繁，把大量而且关系复杂的数据进行整合，二次加工，做个决策分析，这些工作的前提都是要有一个稳定高效的数据库。IBM DB2具有很好的安全性，数据可移植性，其他数据库数据可以移植过来，又善于处理关系复杂的数据，而且速度快，连接方式灵活，可通过 ODBC、JBDC、网络服务、本地客户机或异步客户机接口来实现，总之，相对其他数据库DB2具有明显的优势，正好符合银行的要求。

金融行业使用 DB2 可能是有其历史原因的， 因为金融行业本身用 IBM 的主机就比较多 ：）
还是听金融行业的兄弟们站出来说句吧

大家好
在金融行业中，我想大部分的业务系统使用的是DB2，而绝大部分的经营分析系统用的是teradata，我所知道就有工行，建行，中行，光大，浦发，民生，邮政银行等等，IBM的产品一贯是安全性的代表，在银行交易数据极其重要的前提下，选择DB2是一个不错的选择，同时，DB2的大数据处理速度也仅次于teradata，另外很多银行的硬件选择了IBM的大机，自然iBM的软件产品也是他们考虑的重中之重，至于teradata，在成功实施了walmart，ebay等超大的数据仓库后，在入主中国也强势地拿下了近10省的移动的经分系统和移动集团公司的经分系统，同时又很成功的实施了上海证交所的DW，这些事实的确证明了他们是数据仓库行业的领导者，如果不缺钱，我相信选择teradata做构建EDW是一个不错的选择！

我认为主要有以下几点：
1、历史原因
金融行业对于数据安全和系统可用性要求很高，因此，选用IBM主机的颇多。而DB2最初就是建立在主机操作系统上的，毫无疑问，是与IBM主机配合最好的数据库产品，所以自然就会选择DB2数据库。由于对DB2比较熟悉，在开放式系统上也就选择了DB2数据库。
2、IBM技术支持和售后服务做的很好，产品性价比较高
根据我个人的亲身体验，IBM能够根据客户的需求进行电话或者现场技术支持，能够根据客户要求参与项目建设，与ORACLE相比，售后服务价格相对较低。
3、产品自身为用户提供了较多的监控和分析工具，便于用户自己进行问题诊断和性能优化

⑺ ibm db2 是世上最强数据库吗

DB2和oracle以及MS的SQL Server比的话，某种意义上说，确实是更强的。
Oralce现在比较流行，大中型数据库一般都会使用Oracle，操作确实比DB2更方便，DB2主要是更遵守SQL本身的规则（因为SQL本身就是IBM提出的），并没有像Oracle一样扩展出自己的PL/SQL。所以用起来没那么方便，很多东西需要自己去实现。
但是DB2拥有最好的查询优化器(数据库的核心)，也就意味着它能更高效的处理海量数据。这是其他所有数据库都比不了的。另外还有不少重要特性都比Oracle强一些（比如磁盘负载自动平衡、XML处理能力等）。再配上IBM为DB2量身定制的大型机、小型机，DB2处理海量数据库的性能是其他数据库比不了的，因此各大银行，证券交易所等更多地使用DB2。一般的大中型数据库则用得少，毕竟贵一些，难一些，DB2的必要性淡一些。
很多数据库技术都是IBM首创的，可以说，DB2在技术方面一直是业界领军的。
SQL Server、MySQL之类就不说了，它们主要应用于中小型数据库。跟DB2和Oracle还是有差距的。
不过说世上最强不大合适，毕竟有些数据库在一些特定领域能够有更好的表现。

⑻ 基于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 CreateUserFROM Order WHERE OrderNo IN(SELECT OrderNoFROM OrderDetail WHERE Price= )

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

SELECT CreateUserFROM Order OrderDetailWHERE 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机制来实现控制

lishixin/Article/program/DB2/201311/21921

⑼ DB2和Oracle的区别

Oracle和DB2是两种不同的数据库。
Oracle：
Oracle是甲骨文公司的一款关系数据库管理系统。
ORACLE数据库系统是美国ORACLE公司（甲骨文）提供的以分布式数据库为核心的一组软件产品，是目前最流行的客户/服务器(CLIENT/SERVER)或B/S体系结构的数据库之一。比如SilverStream就是基于数据库的一种中间件。ORACLE数据库是目前世界上使用最为广泛的数据库管理系统，作为一个通用的数据库系统，它具有完整的数据管理功能；作为一个关系数据库，它是一个完备关系的产品；作为分布式数据库它实现了分布式处理功能。
DB2：
全称为IBM DB2。是美国IBM公司开发的一套关系型数据库管理系统，它主要的运行环境为UNIX（包括IBM自家的AIX）、Linux、IBM i（旧称OS/400）、z/OS，以及Windows服务器版本。
DB2主要应用于大型应用系统，具有较好的可伸缩性，可支持从大型机到单用户环境，应用于所有常见的服务器操作系统平台下。 DB2提供了高层次的数据利用性、完整性、安全性、可恢复性，以及小规模到大规模应用程序的执行能力，具有与平台无关的基本功能和SQL命令。DB2采用了数据分级技术，能够使大型机数据很方便地下载到LAN数据库服务器，使得客户机/服务器用户和基于LAN的应用程序可以访问大型机数据，并使数据库本地化及远程连接透明化。 DB2以拥有一个非常完备的查询优化器而着称，其外部连接改善了查询性能，并支持多任务并行查询。 DB2具有很好的网络支持能力，每个子系统可以连接十几万个分布式用户，可同时激活上千个活动线程，对大型分布式应用系统尤为适用。

⑽ 数据库DB2中什么是性能问题

数据库系统主要管理数据库的存储、事务以及对数据库的操作。 文件系统是操作系统管理文件和存储空间的子系统，主要是分配文件所占的簇、盘块或者建立FAT、管理空间空间等。 一般来说数据库系统会调用文件系统来管理自己的数据文件