博主最新文章
博主热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)如何判断的 webpack 打包大小是否科学，是否还有优化的可能？
10:27:51 +08:00 · 4003 次点击
我在项目中用到以下库
vue ， vuex ， vue-router ， vue-resource
materialize
压缩打包后有 700+kb 大小
这科学么？不知道各位打包后的情况怎么样？
我也想问问如何判断 webpack 打包出来到底合不合理？
13 回复 &| &直到
23:23:48 +08:00
& & 10:37:08 +08:00
随手一搜...
而且这些个东西加起来也差不多这么大吧... materialize 都有近 300...
& & 10:46:42 +08:00
webpack 打包以后应该也只会加上一小部分__webpack_require__相关的方法，大头估计还是引用的库。 700+kb 如果在 PC 上的话还好，手机上的话只能做下 gzip+缓存。如果有上 spdy 或者 http/2 的话，可以考虑用 webpack 的 require.ensure ，把模块拆成独立的小文件。
& & 10:59:11 +08:00
700 是 uglify 之前还是之后的。如果是之前的， uglify 一下应该能少一半，再 gzip 下又能少很多。
手机淘宝站首页没 gzip 前是 366kb 。你这还是 spa ， 700 多很正常。
& & 11:10:37 +08:00
uglify 之前是 2.2mb......=。=
看来这还是比较正常的？
& & 11:14:05 +08:00
其实你的依赖库不一定要用 webpack 打包，托管在 CDN 上，一般来说效果会更好
& & 11:19:30 +08:00
@ 作为 spa 可以接受吧，非要用那几个库也没什么办法。现在能做的是想办法弄障眼法， js 加载好之前先弄点等待条， splash screen 之类的糊弄一下。
& & 11:23:35 +08:00
第三方依赖库不建议用 webpack 打包，一般只打包自己的代码
托管在 CDN 一来可以规避浏览器对同域名下并发连接数的限制，二来也有利于 CDN304 读取缓存，三来也缩减 webpack 打包出来文件的体积
& & 11:33:01 +08:00
看来分离第三方库是势在必行了
@
用了这个分析我终于发现大头在哪里了
不是 materialize ，不是 jquery
而是 moment
准确来说应该是 moment 的 locales ，这货压缩后也还有将近 200kb ，里面各种语言的本地化处理，居然这么重.......
我还以为一个时间处理库大不到哪里去.....
& & 11:57:24 +08:00
@ moment 的 locales 可以在 webpack 里面过滤掉
& & 14:27:08 +08:00
@ 可以这样配置一下 用别名
resolve: {
moment: &moment/min/moment-with-locales.min.js&
& & 15:21:39 +08:00
其实这样意义不大，因为这一个就要 195kb
无非是调用 webpack 去压缩，还是直接调用 min 的区别，我估计不会差太多
locales 里面包括了各种英德意法日韩 barbar ，而目前来说，我其实只需要原生的英语，最多加一个中文吧。
其实最好的方法是只打包你要的 locales ，跟 moment 的核心，而不是将全部压缩进去
moment.min.js 只有 41.8kb ，如果加上一个中文支持撑死也就 50kb
相差三倍的大小，还是满可观的
& & 17:51:18 +08:00
固定的 lib 直接用网页引入得了，没必要在打到 build 里，要把 302 有效利用起来嘛
& &256 天前
& · & 611 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 30ms · UTC 20:56 · PVG 04:56 · LAX 13:56 · JFK 16:56? Do have faith in what you're doing.一步步优化JVM&五&：优化延迟或者响应时间(1)
我的图书馆
一步步优化JVM&五&：优化延迟或者响应时间(1)
& & 本节的目标是做一些优化以满足对应用对延迟的需求。这次需要几个步骤，包括完善Java堆大小的配置，评估垃圾回收占用的时间和频率，也许还要尝试切换到不同的垃圾回收器，以及由于使用了不同的垃圾回收器，需要重新优化Java堆空间大小。
& & 这一步有如下可能的结果：
& & 1、应用的延迟需求被满足了。如果这一步的优化操作满足了应用的延迟需求，你可以继续下一步优化（优化吞吐量）。
& & 2、应用的延迟需求未被满足。如果这一步的优化操作未能满足延迟需求，你可能需要重新看看延迟需求是否合理或者修改应用程序。一些可能的问题可以帮助改善应用的延迟问题：
& & a、优化Java堆以及修改应用以减少对象的分配和对象的长时间存活。
& & b、修改JVM的部署结构，让每一个JVM做更少的工作。
& & 上面的两个步骤都可以减少JVM的对象分配，因此减少垃圾回收的频率。
& & 这一步从查看垃圾回收对应用的延迟的影响开始，基于前面一节“决定内存消耗”计算出来的Java堆大小。
& & 下面列出了评估垃圾回收对延迟的影响需要进行的几个事情：
& & 1、测量MinorGC的时间。
& & 2、测量MinorGC的频率。
& & 3、测量FullGC的时间。
& & 4、测量FullGC的频率。
& &&测量垃圾回收的时间的和频率对于改善Java堆大小配置来说是非常重要的。MinorGC的时间和频率的测量结果可以用来改善young代的空间大小。测量最坏情况下FullGC的时间和频率可以用来决定old代的大小，以及是否需要切换成吞吐量垃圾回收器（通过使用-XX:+UseParalleOldGC或者-XX:+UseParallelGC）或者并发垃圾回收器（CMS，通过使用-XX:+UseConcMarkSweepGC）。在使用吞吐量垃圾回收器的时候，如果垃圾回收的延迟和频率太高以导致应用的延迟需求无法满足的时候才切换到CMS，如果选择了切换，需要对CMS垃圾回收器进行优化，后面会详细介绍这个问题。
& & 接下来详细介绍前面提到的各种情况。
& & 下面列举了几个这一步优化操作需求，它们来源于应用的系统需求：
& & 1、可以接收的平均暂停时间。平均暂停时间需求用于和MinorGC消耗的时间比较。
& & 2、可以接收的MinorGC的频率。其实频道对于应用负责人来说，没有平均延迟时间重要。
& & 3、应用负责人能够接受的最大延迟时间。这个时间受到FullGC的影响。
& & 4、应用负责人能够接收的最大延迟的频率，即FullGC的频率。其实，大多数时间应用管理员还是更加关心应用的的最大延迟时间超过了最大延迟的频率。
& & 一旦确定了需求，这些垃圾回收器的时间消耗和频率都可以通过垃圾回收日志收集到。先把垃圾回收器设置为吞吐量垃圾回收器（设置-XX:+UseParallelOldeGC或者-XX:+UseParallelGC）。通过反复测试，可以让young代和old代满足上面的要求。下面2节介绍如何优化young代和old代空间大小来观察MinorGC和最坏情况的FullGC的消耗时间和频率。
& &&改善young代的大小
& & 确定young代的大小是通过评估垃圾回收的统计信息以及观察MinorGC的消耗时间和频率，下面举例说明如何通过垃圾回收的统计信息来确定young代的大小。
& & 尽管MinorGC消耗的时间和young代里面的存活的对象数量有直接关系，但是一般情况下，更小young代空间，更短的MinorGC时间。如果不考虑MinorGC的时间消耗，减少young代的大小会导致MinorGC变得更加频繁，由于更小的空间，用玩空间会用更少的时间。同理，提高young代的大小会降低MinorGC的频率。
& & 当测试垃圾回收数据的时候，发现MinorGC的时间太长了，正确的做法就是减少young代的空间大小。如果MinorGC太频繁了就增加young代的空间大小。
& & 上图是一个展示了MinorGC的例子，这个例子是运行在如下的HotSpot VM命令参数下的。
-Xms6144m&-Xmx6144m&-Xmn2048m&-XX:PermSize=96m&-XX:MaxPermSize=96m&-XX:+UserParallelOldGC&&
& & 上图显示了MinorGC平均的消耗时间是0.05秒，平均的频率是2.147秒1次。当计算MinorGC的消耗时间和频率的时候，越多的数据参与计算，准确性会越高。并且应用要处于稳定运行状态下来收集MinorGC信息也是非常重要的。
& & 下一步是比较MinorGC的平均时间和系统对延迟的要求，如果MinorGC的平均时间大于了系统的要求，减少young代的空间大小，然后继续测试，再收集数据以及重新评估。
& & 如果MinorGC的频率大于了系统的要求，就增加young代的空间大小，然后继续测试，再收集以及重新评估。
& & 也许需要数次重复才能够让系统达到延迟要求。当你改变young代的空间大小的时候，尽量保持old代的空间大小不要改变。
& & 从上图的垃圾回收信息来看，如果应用的延迟要求是40毫秒的话，观察到的MinorGC的延迟是58毫秒，比系统的要求高出了不少。上面例子使用的命令选项是
-Xms6144m&-Xmx6144m&-Xmn2048m&-XX:PermSize=96m&-XX:MaxPermSize=96m&-XX:+UserParallelOldGC&&
& & 意味着old代的空间大小是4096M，减小young代的空间大小的10%而且要保持old代的空间大小不变，可以使用如下选项。
-Xms5940m&-Xmx5940m&-Xmn1844m&-XX:PermSize=96&-XX:MaxPermSize=96&-XX:+UserParallelOldGC&&
& & 注意的是young代的空间大小从2048M减少到1844M，整个Java堆的大小从6144M减少到5940M，两者都是减少了204m。
& & 无论是young的空间调大还是调小，都需要重新收集垃圾回收信息和重新计算MinorGC的平均时间和频率，以达到应用的延迟要求，可能需要几个轮回来达到这个要求。
& & 为了说明了增加young代的大小以降低MinorGC的频率，我们下面举一个例子。如果系统要求的频率是5秒一次，这个上面的例子中是2.147秒一次，也就是说它用了2.147秒，填充满了2048M空间，如果需要5秒一次的频率，那么就需要5/2.147倍的空间，即.147等于4700M。因此young代的空间需要调整到4700M。下面是一个示例来说明配置这个：
-Xms8796m&-Xmx8796m&-Xmn4700m&-XX:PermSize=96m&-XX:MaxPermSize=96m&-XX:+UsePrallelOldGC&&
& & 注意是-Xms和-Xmx也同步调整了。
& & 另外一些调整young代的空间需要注意的事项：
& & 1、old代的空间一定不能小于活动对象的大小的1.5倍。
& & 2、young代的空间至少要有Java堆大小的10%，太小的Java空间会导致过于频繁的MinorGC。
& & 3、当提高Java堆大小的时候，不要超过JVM可以使用的物理内存大小。如果使用过多的物理内存，会导致使用交换区，这个会严重影响性能。
& & 如果在仅仅是MinorGC导致了延迟的情况下，你无法通过调整young代的空间来满足系统的需求，那么你需要重 新修改应用程序、修改JVM部署模型把应用部署到多个JVM上面（通常得要多机器了）或者重新评估系统的需求。
& & 如果通过调整MinorGC能够满足应用的延迟需求，接下来就可以调整old代了，以达到最坏情况下的延迟和延迟频率的需求。下一节详细说明这个问题。
完善old代的大小
& & 这一节的目标是评估由于FullGC引起的最差暂停时间和频率。
& & 同前面一个节“完善young代大小”一样，垃圾回收的统计信息是必须的，在稳定状态下，FullGC的时间表明了应用最差的延迟，如果发生了多个FullGC，计算多个FullGC的平均消耗时间，更多数据能够更好的评估。
& & 计算两次不同的FullGC之间的时间差，可以提供出FullGC的频率，下图用一个列子来说明两个FullGC：
& & 如果没有FullGC，可以人为的去干预，前面说过，可以使用VisualVM来触发FullGC。另外，评估FullGC的频率需要知道对象的转移率，这个转移率说明对象从young代转移到old代。接下来的介绍如何评估转移率。
& & 接下有个几个MinorGC的例子，他们被用来评估FullGC的频率。
T14:40:29.564-0800:&[GC&&[PSYoungGen:&2045989K-&97152K)]&&3634533K-&91456K),&0.0543798&secs]&&[Times:&user=0.38&sys=0.01,&real=0.05&secs]&&
T14:40:31.949-0800:&[GC&&[PSYoungGen:&2047896K-&97152K)]&&3655319K-&91456K),&0.0539614&secs]&&[Times:&user=0.35&sys=0.01,&real=0.05&secs]&&
T14:40:34.346-0800&[GC&&[PSYoungGen:&2045889K-&97152K)]&&3677202K-&91456K),&0.0532377&secs]&&[Times:&user=0.39&sys=0.01,&real=0.05&secs]&&
T14:40:36.815-0800&[GC&&[PSYoungGen:&2047094K-&97152K)]&&3696985K-&91456K),&0.0543332&secs]&&[Times:&user=0.37&sys=0.01,&real=0.05&secs]&&
& & 从上面的例子可以看出：
& & 1、Java堆的大小是6291456K或6144M
& & 2、young代的大小是2097152K或2048M
& & 3、old代的大小是M = 4096M
& & 在这个例子中，活动对象的大小差不多是1370M。那么old代还有2726M剩余空间（M=2726M）。
& & 填充完成2736M空间需要多长时间是由young代向old代的转移率决定的。这个转移率的计算通过查看每次MinorGC后old代的占用空间的增长情况以及MinorGC发生的时间。old代的空间占用是MinorGC之后Java堆中对象大小减去young代的大小，通过这个公式计算，可以看出在这个例子中每次MinorGC之后，old代的空间占用情况是：
& & 1588635K，第一个MinorGC
& & 1611428K，第二次MinorGC
& & 1632106K，第三次MinorGC
& & 1653117K，第四次MinorGC
& & 每次的增量分别是
& & 22793K，第一次和第二次的增量
& & 20678K，第二次和第三次的增量
& & 21011K，第三次和第四次的增量
& & 平均每次MinorGC转移大概201494K或者叫21M。
& & 如果剩余的空间都是按照设个转移率来转移到old代的话，且知道MinorGC的频率是每2.147秒一次。因此，这个转移率是.147s差不多10M/s,那么一共的空间是2736M空间需要273.6s差不多4.5分钟一次。
& & 因此，通过前面的案例分析，应用的最差延迟的频率是4.5分钟。这个评估可以通过让应用处于稳定运行状态超过4.5分钟来验证。
& & 如果评估和观察的FullGC的频率高于了应用对最坏延迟频率的要求，那么可以提高old代的空间大小。如果改变old代的大小，保持young代的空间恒定，在优化young代的时候也说这个问题，两者应该独立优化，以保证有高效。
& & 如果这步已经达到了你最坏延迟的要求，那么这一步调优延迟就算已经完成了，就可以进入下一步去调优“吞吐量”了。
& & 如果你未能达到了应用对最坏延迟时间和频率的性能要求，由于FullGC的执行时间太长了，然后你可以把垃圾回收器切换CMS（concurrent garbage collection）。CMS有能力让垃圾回收尽量是多线程的，即让程序保持在运行状态。要使用CMS可以通过下面这条命令选项:-XX:+UseConcMarkSweepGC。
& & 后面详细说明如何调优CMS。
TA的最新馆藏
喜欢该文的人也喜欢当前位置：
搜狗五笔输入法 V3.0.0.1686不带广告优化安装版搜狗五笔输入法 V3.0.0.1686不带广告优化安装版相关软件软件介绍下载地址相关文章猜你喜欢搜狗五笔输入法（简称搜狗输入法、搜狗五笔）是搜狐公司推出的一款汉字五笔输入法软件，是目前国内主流的五笔输入法之一。号称是当前网上最流行、用户好评率最高、功能最强大的五笔输入法。搜狗输入法与传统输入法不同的是，采用了搜索引擎技术，是第二代的输入法。由于采用了搜索引擎技术，输入速度有了质的飞跃，在词库的广度、词语的准确度上，搜狗输入法都远远领先于其他输入法。搜狗输入法功能介绍多种输入模式向提供便捷输入途径五笔拼音混合输入、纯五笔、纯拼音多种输入模式供用户选择,尤其在混输模式下,用户再也不用切换到拼音输入法下去输入一暂时用五笔打不出的字词了,并且所有五笔字词均有编码提示,是增强五笔能力的有力助手。词库随身：包括自造词在内的便捷的同步功能,对用户配置、自造词甚至皮肤,都能上传下载。人性化设置：兼容多种输入习惯。即便是在某一输入模式下,也可以对多种输入习惯进行配置,如四码唯一上屏,四码截止输入,固定词频与否等等,可以随心所欲的让输入法随你而变。界面美观：兼容所有搜狗拼音可用的皮肤。搜狗手写：在搜狗的菜单选中拓展功能-手写输入安装。手写还可以关联QQ,适合不会打字的人使用。搜狗五笔输入法特色介绍五笔拼音混合输入、纯五笔、纯拼音：多种输入模式向您提供便捷输入途径词库随身：包括自造词在内的便捷同步，搜狗五笔是真正的互联网输入法人性化设置：功能强大，兼容多种输入习惯界面美观：兼容所有搜狗拼音可用的皮肤，资源丰富更新日志搜狗五笔输入法V2.1.0优化打字性能，解决部分win10下打字卡顿问题修正智能造词引起的调频词库冲突优化输入法稳定性搜狗五笔输入法2.0版更新内容：新增功能：1. 添加以z开头的特殊符号输入，方便快捷。2. 词语联想可对词进行联想（如输入“中国”联想“中国人”）。3. 空码时自动查找GBK生僻字。4. 通行证同步和导入配置时，新增对删词信息的合并，使垃圾词不再出现。5. 支持皮肤系列，和搜狗拼音通用，成套皮肤流畅体验。6. 添加输入法管理器，自由设置输入法顺序。7. 新增选项：纯五笔下只在输入4码时显示词组、初始繁/简体状态可设为上次状态、半角状态下输出全角空格。8. 分号模式新增帮助提示窗口。9. 标点符号自动配对（可选）。10. 安装包新增4款冬季和圣诞节主题时尚皮肤，新增两款皮肤系列。11. 精简细胞词库。功能改进：1. 优化打字速度。2. 优化系统词库。 3. 连续按两次分号键，直接上屏分号。4. 优化顶字上屏逻辑，使输入更流畅。5. 按ESC键可关闭软键盘。搜狗五笔输入法不带广告优化安装版的特色：1、添加编辑状态下左ctrl切换临时拼音；2、添加右ctrl切换临时生僻字；3、优化自动造词功能。其他版本下载地址 / Download下载不了？相关文章 / Related Articles猜你喜欢 / Guess You Like《第七章》简单的性能优化
开发中或者是正在运行的系统性能显著恶化的场合，需要进行性能优化。当听到性能优化时，有些人可
能会感觉到非常困难，如果使用OB的话，通过使用索引或者内存等可以非常简单的进行性能优化。这篇
文章将要介绍怎样使用OB简单的使性能优化。
■性能优化是什么
EC系统的“3秒钟规则”
假设在EC网站上，访问网站的顾客都必须要等待三秒钟的响应时间，这个时间被称为“3秒钟规则”。
如果响应时间在三秒钟以上的话，顾客就会认为这个网站服务慢，有可能会导致商业机会的丢失。不用
说EC网站的例子，为了有效的推行业务，系统的性能是非常重要的。系统中并不仅仅要安装重要的功能
（功能需求），还必须要知道响应时间是多少，单位时间内电脑的处理量、通信线路的数据传送量等
（非功能需求）。
数据库即使是在系统开发的后端，也有调整响应时间的性能优化。数据库性能优化就是针对响应时间
非常慢的场合实施的对策。OB有很多功能支持性能优化。
性能优化的流程
以下是包含数据库的一般的性能优化的流程。
&&&&1.调查
&&&&性能优化首先要从性能测定和找到产生问题的地方开始。要把系统构成和应用设计作为优化对象进行确认和测定，调查延迟原因。
&&&&测定方式除了响应时间之外，还可以查看SQL实行计划中“cost”使用量。
&&&&2.设定目标值
接下来，我们要知道要把性能改善到何种程度。进行性能优化有很多种手段，要是全部实施的话将是没完没了的，所以最重要的是设定目标值。要考虑系统至少需要把性能调整到何种程度，例如EC网站要把响应时间缩短到3秒以内等等。
&&&&3.研究改善对策
决定了目标之后就要研究改善对策了。应用逻辑有问题的话就把算法修改成更高效的，SQL有问题的话就把表的关联尽量减少。还有给表设定合适的索引，把外部的应用处理用存储过程的形式。尽量找到达成目标的最有效的方法。
&&&&4.实施/调整
决定了改善对策之后，进入实施阶段，看能否达成目标。如果目标达成了，性能优化就成功了。也有实施对策之后没有达成目标的情况，这时就要重复一遍以上的步骤，改变改善对策。
假如有多个改善对策的话，可以改变改善方法或者是追加改善方法。也许还会遇到其他的瓶颈，这时要返回去重新进行原因分析。在达成目标之前，以上的步骤要循环1~4圈。
所谓瓶颈就是数据库服务器的内存不足，或者SQL的处理速度等数据库外部的性能调整。本篇文章介绍如何使用OB进行数据库优化。
■SQL处理速度的改善（优化索引）
最初运行良好的系统突然变的非常慢，这通常被认为是因为数据的增加使响应速度降低。像这种场合，“优化索引”多次发挥了效果。
优化索引就是给表做成合适的索引，改善性能的方法。如果表中没有索引的话，检索时就是从表所有数据中进行搜索（全表搜索）。进行全表搜索时，如果数据量很大的时候访问速度就会非常慢。这时，如果给表设置合适的索引的话，从大量的数据中有目的的高效的进行搜索，这就可以改善性能。以下是一般优化索引的顺序和OB的功能。
1.抽出运行慢的SQL-->SQL缓存
2.测量SQL的性能-->实行计划
3.做成合适的索引-->索引顾问
使用“SQL缓存”找到SQL性能低下的原因。用“实行计划”测量性能。用“索引顾问”决定改善对策。
抽出速度慢的SQL“SQL捕捉”
接下来要具体介绍“SQL捕捉”的操作方法。为了进行索引优化，首先要从所有的SQL文中找到速度慢的SQL。
SQL捕捉，是跟踪SQL一览表示处理速度和测定结果的功能。此功能在“工具”菜单的“SQL捕捉。
SQL捕捉是为了调查正在运行的SQL所实施的跟踪。跟踪就是对正在运行的SQL的记录。初次启动SQL捕捉时，显示的是跟踪文件存在的文件夹对话框。
关于跟踪文件夹一定要指定成Oracle数据库服务器上跟踪文件存在的文件夹。通常是“Oracle Home/ADMIN/ORCL/UDUMP”。
一定要指定成数据库服务器上的文件夹。安装OB的客户端机器和数据库服务器不同场合，利用操作系统的网络共享功能，指定成客户端和服务器都能参照的文件夹。
TIPS 想要变更跟踪文件存在的文件夹时
在主菜单的“SQLcatch”-->“选择跟踪文件夹”中指定即可。
指定了跟踪文件夹之后，SQL缓存画面就表示出来了。
SQL跟踪的结果被做成日志文件保存在刚刚设置的文件夹内。
点击画面左上角的“开始”按钮，开始跟踪。显示跟踪实行画面，我们要指定对数据库全体进行跟踪还是对个别session进行跟踪。如果要对个别session进行跟踪的话，要选择想要调查的应用对应的session，并且还要在应用中执行登录操作等，做成数据库session。
如果选择对数据库全体进行跟踪的话，就是对所有的session进行跟踪。但是，要把初期化参数“SQL_TRACE”设置成TRUE。
跟踪开始后，可以回到应用页面进行操作。例如，EC网站中商品检索画面缓慢的话，可以执行商品检索操作。这时，正在运行的SQL会记录在跟踪日志中。
操作完成之后，返回到OB，点击“停止”，停止跟踪，接下来确认一下跟踪结果。点击SQL缓存画面的“表示”按钮，跟踪结果画面显示出来。
&&&&COUNT：SQL文实行或者是解析的次数
&&&&CPU：SQL进行解析/实行/取得操作，CPU耗费的时间
&&&&ELAPSED：经过时间
&&&&DISK：实行中读出物理块的次数
&&&&QUERY：SQL语句要求的总读取次数
&&&&CURRENT：SQL语句要求的正在执行的读取次数
&&&&ROWS：实行中处理的行数
&&&&SQL：实行的SQL文
CPU列代表处理速度，点击这些列使他们按照处理速度排序，找到速度慢的SQL。
测量SQL的性能
找到速度慢的SQL之后，在SQL实行画面的“实行计划”功能可以测量SQL的性能。
实行计划”就是在SQL实行之前数据库内部进行的处理。例如，如果是SELECT的话，多表结合的方法、顺序，是否使用索引取得数据，这些都是基于数据库内部的信息决定的。在数据库内部具有决定实行计划功能的部分叫做“优化器”。
在SQL实行画面中点击“实行计划”按钮，“实行计划”按钮是on的状态时，输入SQL文，点击“实行” 按钮，此时进行的是SQL解析，实行计划表示出来。
从SQL缓存画面也可以取得实行计划
在SQL缓存画面选中某行点击鼠标右键，从弹出的对话框中选择“实行计划”即可。
在这之中，索引优化最重要的是以下两点。
实行计划最右面的列就是COST。COST就是数据库处理SQL的负荷，是一项性能指标。COST的单位不是秒，1COST相当于多少秒是受服务器的硬件影响的，所以不能进行严密的换算，可以相对的进行比较。例如，实际上系统的响应时间是30秒，目标值是3秒，只需把COST值缩小10倍就可以了。
是否使用索引
进行全表搜索时（没有使用索引的场合），实行计划的行是红色的。这样就可以知道还可以进行索引优化。
做成合适的索引 “索引顾问”
从实行计划得知没有使用索引时，可以使用OB的索引顾问功能做成索引。如果不使用索引顾问还可以在索引画面手动做成，但是并不是索引使用的越多就越好。
例如“书籍”表，索引是“目次”。一般读者只想读书的一部分的话，首先要参照目次，找到想看的内容的页数。但是如果书只有20几页的话，读者就不需要看目次，直接找到相应的页数。反过来，如果目录有100多页的话，谁也不会使用这么麻烦的东西。
决定实行计划的优化器也认为当记录数很少的时候最好不要使用索引。并且，当索引对象的列很多的时候，因为索引占的空间很大，也不要使用索引。为了作成合适的索引必须要考虑这些问题。但是，使用OB的索引顾问的话，即使不知道这些规则，也可以做出合适的索引。
在使用索引顾问之前
要使用索引顾问，需要做两项准备工作。第一个是作成足够的数据。
前面说到，判断使用索引还是没有使用索引的重要的指标就是数据量。所以，当数据很少时，要使用数据生成工具生成一些数据。
还有就是要获取最新的统计信息。优化器统计表的行数时并不是每次都使用COUNT文，而是从统计信息中取得行数。如果统计信息不是最新的话，优化器就不能做出最好的判断。
获取最新的统计信息的方法是，在对象列表中选中一个表点击鼠标右键，选择“统计信息”，更新画面显示出来。点击“开始”就能取得最新的统计信息。Ctrl+A可以选中所有表。
在统计信息画面有很多选项，因为我们的目的是优化索引，所以选择“收集正确的统计信息”。
基于规则、基于COST
Oracle的优化器有基于规则和基于COST两种模式。上面说到优化器决定实行计划的时候要考虑记录数，这严密的说应该是基于COST场合需要做的。当实行计划是基于规则，则不用考虑记录数，需要遵循一定的规则做出实行计划，例如，使用WHERE句的列是否包含在索引的对象列中。
优化器的模式是基于规则的时候，不需要做成数据和更新统计信息，一般不推荐使用基于规则的模式。刚才图书的例子，参考统计信息的基于COST的方法更好一些。因此，在Oracle10g以后，OB废弃了基于规则的优化器模式。
使用哪个模式可以在初期化参数“OPTIMIZER_MODE”中查询。
准备工作完成之后，启动索引顾问。“工具”-->“索引顾问”。
在索引顾问画面有“输入SQL”，“现在的索引”，“做成的索引”3部分。首先在最上方的“输入SQL”栏中写入要优化的SQL。索引顾问页面和SQL实行画面一样，有履历管理的功能。因为这个履历和SQL实行画面的履历是共有的，所以想在SQL实行画面查询实行计划的话，点击“前”或者是“履历”按钮，就可以呼出同样的SQL。
SQL输入完成后，点击“解析”按钮，在页面中间的“现在的索引”栏内表示的是表和附加在表上的索引的使用状况。没有被使用的索引用红色表示，如果索引不需要了，可以用DELETE键或者点击鼠标右键“消除”进行删除。
在页面下面的“做成的索引”栏中表示的是每个表中被认为是有用的索引。这个栏中表示的是没有被做成的索引，选择一项点击“做成”按钮，索引就被做成了。
但是，我们不知道这样做成的索引是否一定被使用。
索引顾问是解析SQL，得出候补的索引，但是根据记录数的不同，做成的索引是否被优化器使用是不一样的。因此，OB有了比较索引做成前后的COST数的功能。点击“测试”按钮，得到索引做成前和做成后的COST数。
如果做成前和做成后的结果不一样的话，就证明使用了索引。如果结果没变的话，就是即使做成了索引也没有被使用。和实行计划功能一样，性能是用COST表示的，不仅仅是索引的使用状况，根据变化也可以知道性能提高了多少。用户可以按照候补索引的顺序依次测试，选择结果最好的索引。
索引做成之后，会自动进行再解析，最后做成的索引会出现在“现在的索引”栏目中，请确认索引是否被使用。
到此为止索引优化就完成了。
不要使用过多的索引
是每个SQL决定索引是否被使用，最合适的索引是什么依据SQL的不同而不同。一个表不可能只对应一种SQL。即使是不常被更新的主表，除了从管理工具访问之外，还可能和事务内的其他表结合。如果做成多个SQL共同使用的索引很困难的话，那么就给一个表设置多个索引。
但是，索引过多也不好。索引在表中的数据更新的同时会进行再构筑，如果索引多时，就会增加表更新时的负荷。因此，最好是把想要改善性能的SQL和频繁使用的SQL作为索引的对象。
■资源的优化
前面介绍的是通过优化SQL改善性能。如果是因为随着数据量的增加而导致性能恶化的话，这些方法是有效的。但是也有可能是因为内存不足输入输出增加，CPU使用到达界限，数据库服务器的资源不足等。OB有改善这些问题产生的性能恶化的“资源优化”功能。资源优化按照下面的顺序进行。
1.资源状况测定 “性能信息”
2.资源优化 “初期化参数变更”
首先参照Oracle的系统统计和I/O统计等统计信息，然后更改Oracle资源设定中初期化参数的信息。
资源状况测定
OB中使用“性能信息”来调查资源不足的原因。“性能信息”画面在“管理”菜单中。
性能信息画面有系统统计和I/O相关的统计等一些项目。重要的项目在前面用
表示，选择
这个项目就会显示项目的说明和改善方法。
但是多数情况下是确认这些参数在性能刚开始降低时候的值，即使是有专业知识的专家在性能已经恶化的状态下找出原因也是非常困难的。所以，OB提供了定期保存性能信息的功能。保存性能良好时参数的值，这样就可以和性能恶化时的参数值进行比较。
这个功能在“工具”-->“选项”-->“详细设置”中，选择“DB连接结束时自动保存”，设置保存时间间隔。OB终了时如果到了保存间隔的话就会把参数自动保存起来。例如把保存间隔设成30天的话，就是每30天进行一次保存。
被保存起来的信息在性能信息画面表示，可以把性能恶化前和恶化后的值进行比较。
改善初期化参数
在“性能信息”中判定性能恶化的原因是内存等资源不足的情况下，可以使用改变初期化参数的方法进行性能改善。打开“管理”-->“数据库信息”，打开“初期化参数”选项卡。
以下是和性能改善相关的具有代表性的参数。
SGA_MAX_SIZE：
SGA的最大值。SGA（System Global Area）是数据库缓冲区高速缓存和共享池等服务器进程使用的内存区。
DB_CATCH_SIZE：
数据库缓冲区高速缓存大小。它的值越大，访问数据的速度越快。
SHARED_POOL_SIZE：
共享池的大小。它的值越大，程序库缓存的命中率越高，SQL的实行速度越快。
JAVA_POOL_SIZE：
JAVA池的大小。它的值越大，JAVA存储过程等的实行速度越高。
SORT_AREA_SIZE：
排序使用的内存容量。它的值越大，排序的速度越快。
LOG_BUFFER：
把REDO信息写入REDO日志文件时使用的内存容量。它的值越大，写入REDO日志文件的等待时间就越少。
根据Oracle版本的不同，这些项目有可能能修改也有可能不能被修改。“变更”列说明了是否能被修改。
当变更的状态是“可能”时，双击“值”，会出现变更对话框。
“不能”的场合可以更改init.ora或者SPFILE等设定文件，并重新启动数据库。
修改初期化参数是性能优化中非常容易执行的方法，因为要增加Oracle使用的内存空间，所以要先确定服务器剩余的内存容量。
■表访问的优化
表领域的分割
最后介绍一下其他的优化方法。SQL的处理速度非常慢的时候尝试用索引优化的方法，但是却不能把性能提高到目标值。这时，可以使用提高表访问速度的组合分区的方法。
分区是硬盘的读取和写入同时进行的技术。数据库有表领域的概念，表领域实际上是和存放数据的操作系统上的文件有关。表和表领域是从属关系，一个表可能属于一个表领域，但是如果进行分区的话，就可以把表分成几个表领域存放。这样就可以使读取和写入并列化，从末端改善表访问。
分区的顺序
要做成表领域选择“管理”菜单-->“表领域信息”。在表领域一览画面点击“新建”按钮，显示新建画面。
至少要输入的项目是“表领域名”，“文件地址”，“大小”。“文件地址”是服务器上的地址。“大小”是知道表的容量之后设定的。除此之外的项目都不是必须设定的。设定完成后，点击“作成”按钮，表领域就做好了。请按需要添加表领域的数量。
调查表领域所需的大小
表领域必须的数据大小大概是表中各列数据的长度和总数据行数的乘积。但是，严密来说表的block size和INITRANS等表领域相关的设定也是有影响的。把这些也考虑进去计算表领域大小的工具是Oracle免费提供的。
“SI Object Browser ER”也提供了估算表领域大小的功能。
表领域做成之后，在表画面的“领域信息”选项卡内进行设定。表做成时的存放方法是“通常”，这样可指定的表领域就只有一个，如果把存放方法改成“范围分区”，“列表分区”，“散列分区”中的任何一个，就可以分区化。
范围、列表、散列的不同之处是各条数据分配方法的不同。分区的场合指定表中的一列是主键，根据主键对应的值把数据分配在各个分区中。以下是分配方法。
根据值的范围存放在不同的表领域中的方法。指定上限值栏内各个表领域包含的数据的范围来分配表领域。例如，当想根据价格等数值类型、日期类型分配表领域的时候使用。
根据值指定表领域。例如，当想根据价格等数值类型、日期类型分配表领域的时候使用。当输入的值是数据库标识等的时候使用。
当不根据范围和值，随机分配表领域的时候使用。“散列”就是通过“MD5”和“SHA-1”等算法从某个值生成特定的值的算法。在Oracle内部通过散列算法生成值，并根据值分配表领域。当存放的值不一定的场合使用此方法。当不根据范围和值，随机分配表领域的时候使用。“散列”就是通过“MD5”和“SHA-1”等算法从某个值生成特定的值的算法。在Oracle内部通过散列算法生成值，并根据值分配表领域。当存放的值不一定的场合使用此方法。
Oracle中有多种分区方法，我们还可以使用“范围、列表分区”等两种分区方法组合在一起的“综合分区”。
选择了综合分区之后，在分区设定栏的下边会显示叫“子分区”的设定栏。在子分区中可以指定值和表领域。
但是，综合分区的方法在Oracle8i以前的版本不能使用。9i和10g的版本只可以选择“范围、列表分区”或者“范围、散列分区”。11g没有限制了，但是散列只可以作为子分区设定，例如，是不能设定“散列、列表分区”方法的。所以现在可以设定的分区方式有6种，以下是可以组合的分区方式（横列是子分区）。
以上就是使用OB进行的简单的性能优化的方法。要进行性能优化还有一些其他的方法，例如使用存储过程或者是物化视图。首先请先试试上面的方法吧。