VB 数据库 SUM 统计信息 循环统计数据库

dim

xxs

as

integer

For

i

=

0

To

ss

xxs=xxs+

rs.fileds

("金额")

rs.movenext

如何统计出

select

sum(金额)

from

销售

where

品名=use(i)

and

规格=bb(i)

将结果

List1.AddItem

use(i)

&

bb(i)

&

统计出的金额

Next

i

list1.addltem

xxs

有些新手在Oracle数据库中创建索引时往往不会使用可选项 其实 有时候在合适的场合使用一些可选项 可以提高索引的创建速度 如为了大批量导入数据 我们往往会先取消索引其以提高插入的速度 然后等数据导入完毕后再重新创建索引 在这个过程中如果能够采用一些可选项 则可以缩短索引创建的时间 在Oracle数据库中提供了丰富的可选项 我们常用的可选项主要有以下这些

　 　可选项一 NOSORT 记录排序可选项

默认情况下 在表中创建索引的时候 会对表中的记录进行排序 排序成功后再创建索引 但是当记录比较多的是 这个排序作业会占用比较多的时间 这也就增加了索引建立的时间(排序作业是在索引创建作业中完成) 有时候 我们导入数据的时候 如采用insert into 语句插入数据过程中同时采用Order by子句对索引字段进行了排序 此时如果在索引创建过程中再进行排序的话 就有点脱裤子放屁 多此一举了 为此在重新创建索引时 如果表中的数据已经排好序了(按索引字段排序) 那么在创建索引时就不需要为此重新排序 此时在创建索引时 数据库管理员就可以使用NOSORT可选项 告诉数据库系统不需要对表中当记录进行重新排序了

采用了这个选项之后 如果表中的记录已经按顺序排列 那么在重新创建索引的时候 就不会重新排序 可以提高索引创建的时间 节省内存中的排序缓存空间 相反 如果表中的记录是不按索引关键字排序的话 那么此时采用NOSORT关键字的话 系统就会提示错误信息 并拒绝创建索引 所以在使用NOSORT可选项的时候 数据库管理员尽管放心大胆的使用 因为其实在不能够使用这个选项的时候 数据库也会明确的告知 为此其副作用就比较少 数据库管理员只需要把这个可选项去掉然后重新执行一次即可 不过这里需要注意的是 如果表中的记录比较少的话 那么使用NOSORT选项的效果并不是很明显 当采用insert into批量导入数据 并在这个过程中采用了Order by子句对索引关键字进行了排序的话 则此时采用NOSORT选项的话 往往能够起到比较好的效果

可选项二 NOLOGGING 是否需要记录日志信息

在创建索引的时候 系统会把相关的信息存储到日志信息中去 如果表中的记录比较多 则需要一一的把这些信息记录到日志文件中 这显然会让数据库增加很大的工作量 从而增加索引创建的时间 为此在创建索引的过程中 如果有必要时 我们可以采用NOLOGGING选项 让数据库在创建索引的过程中 不产生任何重做日志信息 此时当表中的记录比较多时 就可以明显提高速度

但是默认情况下 数据库在在创建索引时 是不采用这个选项的 即会把相关的信息保存到重做日志中去 这虽然降低了索引创建的效率 但是如果遇到什么意外的话 却可以利用重做日志来进行恢复 所以 此时数据库管理员就比较难以抉择了 一方面是数据的安全 另一方面是索引创建的速度 根据笔者的经验 只要数据库服务器比较稳定 而数据库中约束机制又比较完善的话 那么在创建索引的过程中一般不会出现问题 可以放心大胆的使用这个可选项

但是如果数据库已经使用了好几年了 后来因为某种原因需要重建索引 在这种情况下 由于数据库使用过程中很多因素数据库管理员无法控制 此时为这种类型的数据库创建索引时 为了保险起见还是不要采用这个选项好 因为此时遇到错误的几率相对来说会搞一点 为此此时牺牲一下索引创建的速率 而提高数据的安全性还是有必要的 万一遇到什么问题时 可以通过重做日志来及时的恢复数据 为企业用户减少损失

　 　可选项三 PUTE STATISTICS 是否生成统计信息

如果管理员在创建索引时采用了这个选项 则数据库将在创建索引的过程中以非常小的代价直接生成关于索引的相关统计信息 然后把这些信息存储在数据字典中 这就可以避免以后对索引进行分析统计 而且优化器在优化SQL语句的时候可以随机使用这些统计信息 以确定是否生成使用该索引的执行计划 通常情况下 在生成索引的过程中统计索引的相关信息 其所花的代价是最小的 无论从时间上 还是从硬件资源的耗费上 都是非常小的 所以 在创建索引的过程中统计相关的索引信息是非常有用的

但是默认情况下 数据库是不采用这个选项的 这主要是因为一些事物处理系统 索引的信息是经常需要发生变化的 如果在索引创建的过程中统计了相关信息 这些信息随着索引的调整等等原因会很快的过时 所以说 其在默认情况下没有采用这个选项 可见这个选项并不是在任何情况下都能够起到效果 但是如果这个数据库系统是一个决策支持系统 其数据 索引等等在一段时间内基本上是稳定不变的 此时在创建索引时可以使用这个选项 如此的话 在生成索引时可以以最小的代价生成这些统计信息 方便优化器使用 笔者在部署数据库应用的时候 对于事务型的数据库系统 一般不会启用这个选项 但是对于一些决策性的数据库系统或者数据仓库中 创建索引时则笔者喜欢采用这个选项 这有助于提高数据库的性能 因为优化器在生成执行计划时 可以直接采用这个统计信息 所以 数据库能够在最短的时间内确定需要采用的执行计划 而且在执行计划制定中参考了这个索引统计信息 为此所生成的执行计划在同等条件下可能更加的合理

可选项四 ONLINE DML *** 作与创建索引 *** 作是否可以同时进行

默认情况下 数据库系统是不允许DML *** 作与创建索引的 *** 作同时进行的 也就是说 在创建索引的过程中 是不允许其他用户对其所涉及的表进行任何的DML *** 作 这主要是因为对基础表进行DML *** 作时 会对基础表进行加锁 所以在基础表上的DDL事务没有递交之前 即没有对基础表进行解锁之前 是无法对这基础表创建索引的 反之亦然 显然此时数据库没有采用这个ONLIE选项 继之DML *** 作与创建索引 *** 作同时进行 主要是从创建索引的效率出发的 防止因为两个作业相互冲突 从而延长某个作业的运行时间

但是有时会我们必须允许他们进行同时 *** 作 如用户可能一刻都不能够离开数据库系统 需要时时刻刻对数据库基础表进行DML *** 作 而此时由于某些原因 数据库管理员又需要重新建立索引时 那么不得不在创建索引的语句中加入这个ONLINE选项 让他们同时运行 此时虽然可能会延长索引创建作业的时间 但是可以保障用户DML *** 作能够正常进行 有时候牺牲这个代价是值得的 用户是不能够等的 而我们数据库管理员则可以勉强的等一会儿

当然 如果用户对于这个DML *** 作及时性没有这么高 如数据库管理员在晚上员工没有使用数据库时创建索引时 则可以不带这个选项 在限制用户对基础表进行DML *** 作的同时 提高数据库创建索引的效率

可选项五 PARALLEL 多服务进程创建索引

默认情况下 Oracle数据库系统不采用这个选项 这并不是说这个选项不可用 而是因为大多数情况下企业部署Oracle数据库时所采用的数据库服务器往往只有单个CPU 此时数据库系统是用一个服务进程来创建索引的

如果企业的服务器有多个CPU的话 则可以在创建索引时采用这个选项 因为只要采用了这个选项 则数据库就会使用多个服务进程来并行的创建索引 以提高索引创建的速度 为此 在同等条件下 多服务并行创建进索引并单服务创建索引速度要快的多 所以如果服务器中有多个CPU 而且需要创建的索引比较多或者基础表中记录比较多的话 则采用这个选项能够大幅度的提高索引的创建效率

lishixinzhi/Article/program/SQL/201311/16409

---