大型数据库的优化方法及实例

大型数据库的优化方法及实例

尹德明杨富玉杨莹时鹏泉

中国金融电子化公司

E_mail: dm_mis@https://www.docsj.com/doc/1313485712.html,

1.引言

随着银行业数据集中，作为整个系统核心的数据库，其存放、管理的数据越来越庞大，已经超越GB而到达TB数据量层次，数据库的性能成为整个系统性能的关键。

国库会计核算系统是国库部门用以进行国库业务的会计核算，并通过支付系统、国库内部往来、同城票据交换系统进行资金清算的计算机网络系统。国家金库会计核算系统每天处理的税票数据多达10万笔，税收高峰可能会到100万笔，这样一年累计下来其中历史登记簿中的数据达到2000万条以上，给检索和数据处理带来非常大的困难。

如何对于一个已经上线运行的重要业务系统，通过对数据库的优化和简单的系统流程调整，实现系统性能的大幅提升具有现实、迫切、重要的意义。

2.优化策略

根据Sybase的数据存储机制，在进行一段时期的数据删除、插入和更新等操作后，数据库往往会产生大量的碎片。大量碎片的存在，会严重影响数据库的I/O性能，如果在使用数据库一段时间后，整理碎片，可以提高数据库的性能。由于国家金库会计核算系统在预处理、日间报解、日初始化等步骤，会大批量进行数据删除、插入和更新等操作，因此会产生大量的数据碎片。碎片整理对于国家金库会计核算系统性能优化将会有重要效果。

Sybase Adaptive Server对于按顺序存储和访问的页，在单个I/O中最多读取八个数据页。由于大部分I/O时间都花在磁盘上的物理定位和搜寻上，因此大I/O可极大地减少磁盘访问时间。在大多数情况下，希望在缺省数据高速缓存中配置一个16K缓冲池。为事务日志创建4K缓冲池可极大地减少数据库系统日志写操作的数量。

好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。

3.数据库碎片整理

由于Sybase是通过OAM页、分配单元和扩展页来管理数据的，所以对OLTP应用的Database Server会十分频繁地进行数据删除、插入和更新等操作，时间一长就会出现以下几种情况：

(1)页碎片

即本来可以存放在一个页上的数据却分散地存储在多个页上。如果这些页存储在不同的扩展单元上，Database Server就要访问多个扩展单元，因此降低了系统性能。

(2)扩展单元碎片

在堆表中，当删除数据链中间的记录行时，会出现空页。随着空页的累积，扩展单元的利用率也会下降，从而出现扩展单元碎片。带cluster index的table也有可能出现扩展单元碎片。当有扩展单元碎片存在，会出现以下问题：

对表进行处理时，常常出现死锁；利用较大的I/O操作或增加I/O缓冲区的大小也无法改变较慢的I/O速度；行操作的争用。

（3）扩展单元遍历

带有cluster index的table会由于插入记录而导致页分裂，但当删除记录后，页会获得释放，从而形成跨几个扩展单元和分配单元的数据，而要访问该数据就必须遍历几个扩展单元和分配单元。这将导致访问/查询记录的时间大大延长，开始时数据库的性能虽然较高，

但使用一段时间后性能就会下降等问题。

实际上，数据在存储空间上排列得越紧密有序，Database Server访问的速度就越快，消除碎片有助于提高系统的性能和更有效地利用数据存储空间。

(4) 碎片优化方法

处理碎片有多种方法，如重新定义table的填充因子，根据table的定义删除并重新创建索引、重建表等。

可以采用重新创建聚簇索来整理数据库碎片，这样的好处是碎片整理和索引优化可以同时进行。如对table_name进行重建索引。

if exists (select 1 from sysindexes where id = object_id('table_name')

and name = 'PK_HTD_BYSSRHZ' and indid > 0 and indid < 255) alter table 'table_name drop constraint PK_HTD_BYSSRHZ

alter table 'table_name’add constraint PK_HTD_BYSSRHZ PRIMARY KEY CLUSTERED (zwrq,skgkdm,ssgkdm,mdgkdm,ysjc,yszl, jgdm,

bjcs,sjbz,kmdm,ssyf,fczbz)

4．内存优化

(1)配置16K缓冲池为总数据高速缓存的25%

sp_poolconfig 'default data cache',35M','16K'

(2)配置4K缓冲池为总数据高速缓存的15%

sp_poolconfig 'default data cache',21M','4K'

5.索引调优

好的性能离不开优良的数据库设计，数据库性能优化的目标就是尽量减少I/O，提高吞吐量，从而缩短系统的响应时间，而实现这一目标的重要手段之一——就是创建合理的索引：

索引可以起到以下作用：

(1) 避免表扫描；

(2) 点查询中定位包含特定数据的特定数据页；

(3) 范围(域)查询确定上下限；

(4) 索引覆盖，完全避免存取数据页；

(5) 连接时避免排序。

建立索引的注意事项：

(1) Unique和primary key可以创建唯一索引，缺省情况下unique创建nonclustered，

primary key创建clustered索引；

(2) Allpages表一般都需要创建clustered索引或分区以减少最后一页的争夺；

(3) 如果需要大量插入，不要将clustered索引建立在单调上升的字段上，如identity；

对于dol表，此问题并不严重，但allpages却往往是锁争夺的根源；

(4) 对allpages表，如有可能不要将clustered索引建立在频繁更新的字段上；

(5) 使用索引覆盖来进行关键查询和不太频繁的查询；

(6) 如果索引字段元唯一建立唯一索引，优化程序知道只有一行纪录匹配；

(7) 索引键尽可能小，如果可能使用最小的数据类型。确保连接字段元数据类型相同，

如果连接查询需要转换数据类型就不能使用索引；

(8) 使用索引尽可能使用前导列能够提供良好的性能（即前导列要具备一定的选择性）。

6. 代码调优

代码优化包括两个方面：(1)、SQL语句的优化；(2)、代码流程设计的优化。性能

低下的SQL语句往往来自于不恰当的索引设计、不充分的连接条件和不可优化的where 子句；所以对于性能要求较高的功能模块中，我们通常需要考虑上述几个方面，从而写出性能优良的SQL语句；但是，在某些情况下，优良的SQL语句也不能完全解决性能问题，比如说：某个SQL语句对一个有200万笔数据的表进行检索，用时0.1秒，我想这样的性能应该说已经不错了，然而，如果在代码流程设计上需要对该语句循环1000次，那么对于该功能模块的整体性能来说，可能还是无法满足性能要求，所以说对于性能要求高的功能流程设计需要遵循一个原则：尽量减少检索表的次数。

(1)SQL语句优化

不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的。

在where子句中对列使用任何操作（比如：函数）都是在SQL运行时逐列计算得到的，因此查询优化器即使知道使用索引，也不得不进行部分或全部表扫描，以至于降低性能；然而对SQL语句换一种写法，可能有些结果在查询编译时就能得到，从而可以被SQL优化器优化，使用索引，避免表搜索。如将代码：select max(zwrq) from table_name where substring(zwrq,1,6) = '200305'修改成select max(zwrq) from table_name where zwrq >= '20030501' and zwrq <= '20030531'和select max(zwrq) from table_name where zwrq like '200305%'

建立充分的连接条件。多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充分考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数×内层表中每一次查找的次数来确定，乘积最小为最佳方案。

(2) 代码流程设计的优化

在大型数据库中，如何提高数据操作效率值得关注。可以根据不同系统的实际情况对代码流程进行优化。如：

根据业务规则减少访问表的个数；通过预取多个SQL语句共用的查询条件，替代Where 子句的自查询，从而简化了Sql语句的复杂度；减少对表检索的次数；由汇总某旬的所有发生额改为汇总该旬最大账务日期的最大报解次数的旬累计，从而减少数据库的吞吐量；对账部分的实现由游标循环对账改为通过内外两次表连接（即检索两次表）对账，从而大大减少了检索表的次数。

7.结论

经过数据库碎片整理，索引调优，内存优化，代码优化后，我们对某分库进行了导出数据接口和对账测试，测试表明优化取得了很大效果，优化是成功的。

大型ORACLE数据库优化设计方案

大型ORACLE数据库优化设计方案 本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。 对于ORACLE数据库的数据存取，主要有四个不同的调整级别，第一级调整是操作系统级 包括硬件平台,第二级调整是ORACLE RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不 同方面介绍ORACLE数据库优化设计方案。 一.数据库优化自由结构OFA(Optimal flexible Architecture) 数据库的逻辑配置对数据库性能有很大的影响,为此,ORACLE公司对表空间设计提出了一种优化结构OFA。使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构OFA,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。数据库逻辑设计的结果应当符合下面的准则：(1)把以同样方式使用的段类型存储在一起； (2)按照标准使用来设计系统；(3)存在用于例外的分离区域；(4)最小化表空间冲突；(5)将数 据字典分离。 二、充分利用系统全局区域SGA(SYSTEM GLOBAL AREA) SGA是oracle数据库的心脏。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA 包括以下几个部分： 1、数据块缓冲区(data block buffer cache)是SGA中的一块高速缓存，占整个数据库大小 的1%-2%，用来存储从数据库重读取的数据块(表、索引、簇等)，因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表 说明和权限，它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法 管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。 另外，SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这

数据库优化服务(外文翻译)

吉林化工学院理学院 毕业论文外文翻译 阿德里恩.甘卡，伊莫.盖格尔罗马尼亚布加勒斯特迪杜奥列斯库大学德国派尔博登施泰特威廉学校 数据库优化服务Database Optimizing Services 学生学号：******** 学生姓名：*** 专业班级：信息与计算科学0801 指导教师：*** 职称：教授 起止日期：2012.2.27～2012.3.14 吉林化工学院 Jilin Institute of Chemical Technology

数据库优化服务 摘要 几乎每一个组织都存在它的中心数据库。数据库为不同的活动提供支持，无论是生产，销售和市场营销或内部运作。为了获得战略决策的帮助，一个数据库每天都在被访问。要满足这种需求，因此需要与高品质的安全性和可用性。 为实现一些需求所使用的DBMS（数据库管理系统），事实上，是一个数据库软件。从技术上讲，它是软件，它采用了标准的编目，恢复和运行不同的数据查询方法。DBMS 管理输入数据，组织安排这些数据，并提供它的用户或其他程序修改或提取数据的方法。数据库管理就是一种需要定期更新，优化和监测的操作。 关键词 数据库，数据库管理系统（DBMS），索引，优化，成本，优化数据库。

1 引言 该文件的目的是介绍有关数据库的基本优化代表的观念，在不同类型的查询中使用数学估计成本，可以达到性能水平的审查，以及分析在特定查询的例子中不同的物理访问结构的影响。目标群体应该熟悉SQL在关系数据库的基本概念。 通过这种方式，可以执行复杂的查询策略，允许以较低的成本获得信息的使用知识。一个数据库经过一系列转换，直到其最终用途，以数据建模，数据库设计和开发为开始，以维护和优化为结束。 2 数据库建模 2.1 数据建模 数据模型更侧重于数据是必要的，而做出数据的方式应该是一种有组织的和少操作的方式。数据建模阶段涉及结构的完整性，操作和查询。这有多个这方面的事项，如：1。数据定义方式应该是有组织的（分层网络，关系和重点对象）。这需要提供一个规则，来约束实例的定义结构的允许/限制。 2。提供了数据更新协议。 3。提供了数据查询的方法。 一个结构简单的数据通信，能够使得最终用户很容易的理解，是数据建模想要的的实际结果。 2.2 自定义数据库/数据库发展 数据库的开发和自定义答复了顾客的需求。自定义数据库的重要性主要体现在通过它，使向目标客户直接提供服务的产品的商业化成为可能。一个数据库的质量通过定期更新来维护。 2.3 数据库设计 如果数据库有以下任何问题，如故障，不安全或不准确的数据或数据库退化，失去了其灵活性，那么是时候换新数据库了。因此，必须定义具体的数据类型和存储机制以便通过规则和正确地运用操作机制，确保数据的完整性。所有数据库应构建一个客户方面的规范，包括它的用户界面和功能。通过这些可以使运用数据进入一个网站成为可能。

OLTP数据库优化方案

OLTP数据库优化方案及案例
ORACLE数据库SQL优化方案、案例
Edgar Liu
? 2015 Huatek CO., LTD. All Rights Reserved.
2015.3.17

目录
1. 优化方案与基础知识
1.1 问题SQL来源（现象） 1.2 数据库性能优化方案及期待效果 1.3 优化方法论及优化分析树 1.4 数据库体系结构 1.5 逻辑读 逻辑写
4.索引设计与查询条件
4.1 4.2 4.3 4.4 索引介绍 索引设计步骤 索引创建原则 索引失效与不足
2. 执行计划分析
2.1 执行计划查看方法 2.2 执行计划示例 2.3 执行计划三部分 2.4 硬解析和软解析
5. 高效SQL
5.1 5.2 5.3 5.4 优化规则30条 关于Hit提示优化 DML语句优化 批量读取游标数据优化
3.最佳表连接方式
3.1 3.2 3.3 3.4 ORACLE表介绍 RDBMS表连接方式介绍 执行计划中表连接方式介绍 执行计划中表连接方式比较
6. 数据模型与SQL
6.1 数据逻辑模型设计 6.2 数据库物理设计 6.3 书集推荐
2/40

1.0 OLTP 与OLAP区别
?对于Oracle数据库的数据存取，主要有四个不同的调整级别， ?第一级调整是操作系统级包括硬件平台, ?第三级是Oracle数据库设计级的调整, 第二级调整是Oracle RDBMS级的调整, 第四级调整级是SQL级。通常依此四级调整级别对数据库进行调
整、优化，数据库的整体性能会得到很大的改善。
3/40

大型数据库的优化方法及实例

大型数据库的优化方法及实例 尹德明杨富玉杨莹时鹏泉 中国金融电子化公司 E_mail: dm_mis@https://www.docsj.com/doc/1313485712.html, 1.引言 随着银行业数据集中，作为整个系统核心的数据库，其存放、管理的数据越来越庞大，已经超越GB而到达TB数据量层次，数据库的性能成为整个系统性能的关键。 国库会计核算系统是国库部门用以进行国库业务的会计核算，并通过支付系统、国库内部往来、同城票据交换系统进行资金清算的计算机网络系统。国家金库会计核算系统每天处理的税票数据多达10万笔，税收高峰可能会到100万笔，这样一年累计下来其中历史登记簿中的数据达到2000万条以上，给检索和数据处理带来非常大的困难。 如何对于一个已经上线运行的重要业务系统，通过对数据库的优化和简单的系统流程调整，实现系统性能的大幅提升具有现实、迫切、重要的意义。 2.优化策略 根据Sybase的数据存储机制，在进行一段时期的数据删除、插入和更新等操作后，数据库往往会产生大量的碎片。大量碎片的存在，会严重影响数据库的I/O性能，如果在使用数据库一段时间后，整理碎片，可以提高数据库的性能。由于国家金库会计核算系统在预处理、日间报解、日初始化等步骤，会大批量进行数据删除、插入和更新等操作，因此会产生大量的数据碎片。碎片整理对于国家金库会计核算系统性能优化将会有重要效果。 Sybase Adaptive Server对于按顺序存储和访问的页，在单个I/O中最多读取八个数据页。由于大部分I/O时间都花在磁盘上的物理定位和搜寻上，因此大I/O可极大地减少磁盘访问时间。在大多数情况下，希望在缺省数据高速缓存中配置一个16K缓冲池。为事务日志创建4K缓冲池可极大地减少数据库系统日志写操作的数量。 好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。 3.数据库碎片整理 由于Sybase是通过OAM页、分配单元和扩展页来管理数据的，所以对OLTP应用的Database Server会十分频繁地进行数据删除、插入和更新等操作，时间一长就会出现以下几种情况： (1)页碎片 即本来可以存放在一个页上的数据却分散地存储在多个页上。如果这些页存储在不同的扩展单元上，Database Server就要访问多个扩展单元，因此降低了系统性能。 (2)扩展单元碎片 在堆表中，当删除数据链中间的记录行时，会出现空页。随着空页的累积，扩展单元的利用率也会下降，从而出现扩展单元碎片。带cluster index的table也有可能出现扩展单元碎片。当有扩展单元碎片存在，会出现以下问题： 对表进行处理时，常常出现死锁；利用较大的I/O操作或增加I/O缓冲区的大小也无法改变较慢的I/O速度；行操作的争用。 （3）扩展单元遍历 带有cluster index的table会由于插入记录而导致页分裂，但当删除记录后，页会获得释放，从而形成跨几个扩展单元和分配单元的数据，而要访问该数据就必须遍历几个扩展单元和分配单元。这将导致访问/查询记录的时间大大延长，开始时数据库的性能虽然较高，

数据库设计与优化

一、数据库结构的设计 如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器端程序的编程和维护的难度，而且将会影响系统实际运行的性能。所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。 在一个系统分析、设计阶段，因为数据量较小，负荷较低。我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。 所以在考虑整个系统的流程的时候，我们必须要考虑，在高并发大数据量的访问情况下，我们的系统会不会出现极端的情况。（例如：对外统计系统在7月16日出现的数据异常的情况，并发大数据量的访问造成，数据库的响应时间不能跟上数据刷新的速度。具体情况是：在日期临界时（00：00：00），判断数据库中是否有当前日期的记录，没有则插入一条当前日期的记录。在低并发访问的情况下，不会发生问题，但是在当日期临界时的访问量相当大，且在做这一判断的时候，会出现多次条件成立，则数据库里会被插入多条当前日期的记录，从而造成数据错误。），数据库的模型确定下来之后，我们有必要做一个系统内数据流向图，分析可能出现的瓶颈。 为了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。（例如用户表的地区，我们可以把地区另外存放到一个地区表中）如果数据冗余低，数据的完整性容易得到保证，提高了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。而对于多表之间的关联查询（尤其是大数据表）时，其性能将会降低，同时也提高了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量大小、数据项的访问频度，对此类数据表频繁的关联查询应适当提高数据冗余设计但增加了表间连接查询的操作，也使得程序的变得复杂，为了提高系统的响应时间，合理的数据冗余也是必要的。设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。 另外，最好不要用自增属性字段作为主键与子表关联，不便于系统的迁移和数据恢复。 原来的表格必须可以通过由它分离出去的表格重新构建。使用这个规定的好处是，你可以确保不会在分离的表格中引入多余的列，所有你创建的表格结构都与它们的实际需要一样大。应用这条规定是一个好习惯，不过除非你要处理一个非常大型的数据，否则你将不需要用到它。（例如一个通行证系统，我可以将USERID，USERNAME，USERPASSWORD，单独出来做个表，再把USERID作为其他表的外键） 表的设计具体注意的问题： 1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。 2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。 3、对于不可变字符类型char和可变字符类型varchar 都是8000字节，char 查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。在设计

MySQL数据库性能(SQL)优化方案-期末论文

高级数据库技术——期末论文 基于SQL查询的MySQL数据库性能优化研究 ：XX 学号:2014XXXXX 学院：计算机学院

摘要： 查询是数据库系统中最基本也是最常用的一种操作，是否具有较快的执行速度，已成为数据库用户和设计者极其关心的问题。在研究开源数据库管理系统MySQL 查询优化技术的基础上，主要结合传统SQL操作优化、深度分析 MySQL 源代码、现代数据库发展几方面进行诸如参数调优，MySQL关联查询，重写相关规则等容展开优化分析研究。 关键词：查询优化，查询重用，查询重写，计划优化

一、传统SQL查询优化操作 1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2.使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo ) 使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，

SQL Server数据库优化方案汇总

SQL Server数据库优化方案汇总 50种方法优化SQL Server 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化 可以通过如下方法来优化查询 : 1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要. 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使 用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段 5、提高网速; 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行 配置。运行 Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。如果另外安装了全文检索功能，并打算 运行 Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍（虚拟内存大小设置的一半）。 7、增加服务器 CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成 多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并 行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert， Delete还不能并行处理。 8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。 9、DB Server 和APPLication Server 分离；OLTP和OLAP分离

大数据库优化(SQLServer)

SQL SERVER性能优化综述 近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以 前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能 性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效 率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三

数据库优化设计方案

数据库优化方案设计 XX信息管理平台从大型数据库环境四个不同级别的调整分析入手，分析数据库平台的系统结构和工作机理，从九个不同方面设计数据库的优化方案。 对于数据库的数据优化，主要有四个不同的调整级别，第一级调整是操作系统级包括硬件平台，第二级调整是RDBMS级的调整，第三级是数据库设计级的调整，最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不同方面介绍数据库优化设计方案。 一、数据库优化自由结构 数据库的逻辑配置对数据库性能有很大的影响。为此，数据库平台一般对表空间设计提出有相应的优化结构，如ORACLE公司的OFA(Optimal flexible Architecture)，使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构，简单地讲就是在数据库中可以高效自由地分布逻辑数据对象，因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类，这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。 数据库逻辑设计的结果应当符合下面的准则： （1）把以同样方式使用的段类型存储在一起； （2）按照标准使用来设计系统； （3）存在用于例外的分离区域； （4）最小化表空间冲突； （5）将数据字典分离。 二、充分利用系统全局区域 系统全局区域是数据库平台的心脏，如Oracle数据库的SGA（SYSTEM GLOBAL AREA) 。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA包括以下几个部分： 1、数据块缓冲区（data block buffer cache）是SGA中的一块高速缓存，占整个数据库大小的1%-2%，用来存储从数据库重读取的数据块（表、索引、簇等），因此采用least recently used (LRU，最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表说明和权限，它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU 算法管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。 另外，SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这些内存缓冲区的合理设置，可以大大加快数据查询速度，一个足够大的内存区可以把绝大多数数据存储在内存中，只有那些不怎么频繁使用的数据，才从磁盘读取，这样就可以大大提高内存区的命中率。 三、规范与反规范设计数据库

浅谈数据库系统优化

浅谈数据库系统优化 概要：数据库系统的优化可以有效提高系统的性能，微软的SQL Server数据库的优化是一个系统工程，需要从设计开始就进入优化程序。 数据库的性能的优化成了数据处理的一个很重要环节。系统的性能优化应该贯穿系统工作的整个生命周期，从开发开始直到系统最终下线，都应该不断的动态的优化并不断调整优化过程。基于SQL Server的数据库优化是指对数据库处理、存储、查询等进行调优的过程。 基于SQL Serve数据库的优化，应该从数据库设计的时候就做好优化打算，为后面系统正式投入运行后优化做好准备。其主要策略有： 1）调优数据库。数据库性能的优化基础就是数据库的基本设计，如果设计端出了问题则对数据库的影响很大，也很有可能没有优化的必要。数据库的优化应该从数据库的设计开始，一般要找专业的性能优化专家根据系统的要求，对数据库采取合理的设计方案。数据库的设计主要包含两个部分，一个是数据库存储分配的物理设计，一个是数据流量分配的逻辑设计。物理设计主要包括数据对象在物理介质上存储分布等各个方面，所要注意的问题就是在不同的存储介质上所放的数据块的大小，这个直接关系到数据的存储速度。而逻辑设计主要包括在数据库的索引、数据库模式、视图等。数据库的设计是基础，如果在设计初始出了问题，则不可能通过单纯的优化来完成数据库的正常工作，所以这是数据库调整和优化的保障。 2）优化应用程序。网络中数据的查询和传输速度及效率不仅仅在于服务器，而是和多种因素相关联的，根据网络上的相关统计，对和数据库相关的各个外部因素进行调整，同样可以达到数据库性能优化的目的。相关因素主要包括，网络、操作系统、硬件、数据库参数等各个方面。而这因素大都设计硬件设备，其它软件方面主要是应用程序的优化，包括数据库的SQL语句和系统开发语言的优化。在数据库的应用中，大部分是通过SQL语句来实现的，因此SQL语句的优化对数据系统优化起到很重要的作用。 大多数针对系统应用程序的优化也都集中在查询语句的处理上，而SQL语句的优化则可集中到合理利用临时数据表及索引。充分利用临时数据表，及建立合理的索引、调整优化SQL语句，等可以减少客户访问数据库的次数，减小CPU

数据库优化

关于数据库优化方面的文章很多，但是有的写的似是而非，有的不切实际，对一个数据库来说，只能做到更优，不可能最优，并且由于实际需求不同，优化方案还是有所差异，根据实际需要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面往往又是相互矛盾的，下面结合网上的一些看法和自己的一些观点做个总结。 一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 2、合理的冗余 完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。 冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。 冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。 3、主键的设计 主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。 在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。 主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前

SQL数据库优化方法

SQL数据库优化方法

目录 1 系统优化介绍 (1) 2 外围优化 (1) 3 SQL优化 (2) 3.1 注释使用 (2) 3.2 对于事务的使用 (2) 3.3 对于与数据库的交互 (2) 3.4 对于SELECT *这样的语句， (2) 3.5 尽量避免使用游标 (2) 3.6 尽量使用count(1) (3) 3.7 IN和EXISTS (3) 3.8 注意表之间连接的数据类型 (3) 3.9 尽量少用视图 (3) 3.10 没有必要时不要用DISTINCT和ORDER BY (3) 3.11 避免相关子查询 (3) 3.12 代码离数据越近越好 (3) 3.13 插入大的二进制值到Image列 (4) 3.14 Between在某些时候比IN 速度更快 (4) 3.15 对Where条件字段修饰字段移到右边 (4) 3.16 在海量查询时尽量少用格式转换。 (4) 3.17 IS NULL 与IS NOT NULL (4) 3.18 建立临时表， (4) 3.19 Where中索引的使用 (5) 3.20 外键关联的列应该建立索引 (5) 3.21 注意UNion和`UNion all 的区别 (5) 3.22 Insert (5) 3.23 order by语句 (5) 3.24 技巧用例 (6) 3.24.1 Sql语句执行时间测试 (6)

1系统优化介绍 在我们的项目中，由于客户的使用时间较长或客户的数据量大，造成系统运行速度慢，系统性能下降就容易造成数据库阻塞。这是个非常痛苦的事情，用户的查询、新增、修改等需要花很多时间，甚至造成系统死机的现象。速度慢的原因主要是来自于资源不足。 数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来最多只占数据库系统性能提升的40%左右(我将此暂时称之为外围优化)；其余大部分系统性能提升来自对应用程序的优化，对于应用程序的优化可以分为对源代码的优化及数据库SQL语句的优化。在本文档只介绍外围优化及SQL语句的优化，对于源代码的优化需要相关方面的专家，形成统一的规范。 一个数据库系统的生命周期可以分成：设计、开发和成品三个阶段。在设计阶段进行数据库性能优化的成本最低，收益最大。在成品阶段进行数据库性能优化的成本最高，收益最小。规范的代码和高性能的语句，功在平时，利在千秋。 2外围优化 1、将操作系统与SQL数据库的补丁打到最高版本，WIN2003最高补丁是SP4， SQL SERVER2000最高补丁是SP4(版本号：2039)。 2、在服务器上不要安装与VA程序任何无相关的软件，甚至一些与VA运行 无关的服务都可以停掉。一般只安装SQL数据库、VA服务端服务及杀毒 软件。 3、杀毒软件避免对大文件进行扫描，特别是数据库（MDF和LDF）文件，一 定要从杀毒软件的范围内排除掉。 4、在进行服务器分区时，分区不要太多，两三个分区就可以了。分区最好 都使用NTFS格式。

千万级的mysql数据库与优化方法

千万级的mysql数据库与优化方法 1.对查询进行优化，应尽量避免全表扫描，首先应考虑在where 及order by 涉及的列上建立索引。 2.应尽量避免在where 子句中对字段进行null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： Sql代码 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： Sql代码 3.应尽量避免在where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：Sql代码 可以这样查询： Sql代码 5.in 和not in 也要慎用，否则会导致全表扫描，如： 对于连续的数值，能用between 就不要用in 了： 6.下面的查询也将导致全表扫描： Sql代码

若要提高效率，可以考虑全文检索。 7.如果在where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描： Sql代码 可以改为强制查询使用索引： 8.应尽量避免在where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如： 应改为: 9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：Sql代码 应改为: 10.不要在where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。 11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。 12.不要写一些没有意义的查询，如需要生成一个空表结构：

MySQL数据库性能(SQL)优化方案

MySQL数据库性能（SQL）优化方案本文探讨了提高MySQL 数据库性能的思路，并从8个方面给出了具体的解决方法。 1、选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN 来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2、使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

sql优化方案讲解

Sql优化方案 一．数据库优化技术 1.索引（强烈建议使用） 1.1优点 创建索引可以大大提高系统的性能。 第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。 第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。 第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。 第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。 第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。 1.2 缺点 第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。 第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。 1.3 使用准则 索引是建立在数据库表中的某些列的上面。因此，在创建索引的时候，应该仔细考虑在哪些列上可以创建索引，在哪些列上不能创建索引。 一般来说，应该在这些列上创建索引。 第一，在经常需要搜索的列上，可以加快搜索的速度；

第二，在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构； 第三，在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；第四，在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的； 第五，在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间； 第六，在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。 同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点： 第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。 第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。 第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。 第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。 1.4 总结 1）索引提高了数据库的检索性能，但一定程度上牺牲了修改性能。因此适用于“多查询少修改”（insert，update，delete）的表。 2）对此类表中的外键，需要分组，排序或作为检索条件的字段建立索引 3）对此类表中查询使用少，字段取值少，字段数据量大的不应创建索引

数据库优化方案

数据库优化方案 1. 高效地进行SQL语句设计： 通常情况下，可以采用下面的方法优化SQL对数据操作的表现： （1）减少对数据库的查询次数，即减少对系统资源的请求，使用快照和显形图等分布式数据库对象可以减少对数据库的查询次数。 （2）尽量使用相同的或非常类似的SQL语句进行查询，这样不仅充分利用SQL共享池中的已经分析的语法树，要查询的数据在SGA中命中的可能性也会大大增加。 （3）避免不带任何条件的SQL语句的执行。没有任何条件的SQL语句在执行时，通常要进行FTS，数据库先定位一个数据块，然后按顺序依次查找其它数据，对于大型表这将是一个漫长的过程。 （4）如果对有些表中的数据有约束，最好在建表的SQL语句用描述完整性来实现，而不是用SQL程序中实现。 一、操作符优化： 1、IN操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的，从Oracle执行的步骤来分析用IN的SQL与不用IN 的SQL有以下区别： ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL 至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL 就不能转换了。在业务密集的SQL当中尽量不采用IN操作符。 优化sql时，经常碰到使用in的语句，一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。 2、 NOT IN操作符 强列推荐不使用的，因为它不能应用表的索引。用NOT EXISTS或（外连接+判断为空）方案代替 3、IS NULL或IS NOT NULL操作 判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。 用其它相同功能的操作运算代替，a is not null改为 a>0 或a>’’等。 不允许字段为空，而用一个缺省值代替空值，如业扩申请中状态字段不允许为空，缺省为申请。 避免在索引列上使用IS NULL和IS NOT NULL 避免在索引中使用任何可以为空的列，ORACLE将无法使用该索引．对于单列索引，如果列包含空值，索引中将不存在此记录.对于复合索引，如果每个列都为空，索引中同样不存在此记录.如果至少有一个列不为空，则记录存在于索引中．举例:如果唯一性索引建立在表的A 列和B 列上,并且表中存在一条记录的A,B 值为(123,null) , ORACLE 将不接受下一条具有相同A,B值（123,null）的记录(插入).然而如果所有的索引列都为空，ORACLE将认为整个键值为空而空不等于空.因此你可以插入1000 条具有相同键值的记录,当然它们都是空!因为空值不存在于索引列中,所以

数据库优化查询计划的方法

数据库优化查询计划的方法 数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。 在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。 分析问题 许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。

一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化 处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优 化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此所写语句的优劣至关重要。下面重点说明改善查询计划的解决方案。 解决问题 下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。 1．合理使用索引 索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如