存储过程性能优化

① 数据库性能优化有哪些措施

1、调整数据结构的设计

这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。

2、调整应用程序结构设计

这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。

3、调整数据库sql语句

应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器(OracleOptimizer)和行锁管理器(row-levelmanager)来调整优化SQL语句。

4、调整服务器内存分配

内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区(SGA区)的数据缓冲区、日志缓冲区和共享池的大小;还可以调整程序全局区(PGA区)的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用操作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。

5、调整硬盘I/O

这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。

6、调整操作系统参数

例如：运行在UNIX操作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。

实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。

一、ORACLE数据库性能优化工具

常用的数据库性能优化工具有：

ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。

操作系统工具，例如UNIX操作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现在什么地方有时候很有用。

SQL语言跟踪工具(SQLTRACEFACILITY)，SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文件，管理员可以使用TKPROF工具查看这些文件。

ORACLEEnterpriseManager(OEM)，这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。

EXPLAINPLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。

二、ORACLE数据库的系统性能评估

信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。

1、在线事务处理信息系统(OLTP)，这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数：

数据库回滚段是否足够?

是否需要建立ORACLE数据库索引、聚集、散列?

系统全局区(SGA)大小是否足够?

SQL语句是否高效?

2、数据仓库系统(DataWarehousing)，这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数：

是否采用B*-索引或者bitmap索引?

是否采用并行SQL查询以提高查询效率?

是否采用PL/SQL函数编写存储过程?

有必要的话，需要建立并行数据库提高数据库的查询效率

三、SQL语句的调整原则

SQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAINPLAN语句来比较各种实现方案，并选出最优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则：

1、尽量使用索引。试比较下面两条SQL语句：

语句A：SELECTdname,

(SELECTdeptnoFROMemp);

语句B：SELECTdname,deptnoFROMdeptWHERENOTEXISTS

(SELECTdeptnoFROMempWHEREdept.deptno=emp.deptno);

这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。

2、选择联合查询的联合次序。考虑下面的例子：

SELECTstuffFROMtabaa,tabbb,tabcc

WHEREa.acolbetween:alowand:ahigh

ANDb.bcolbetween:blowand:bhigh

ANDc.ccolbetween:clowand:chigh

ANDa.key1=b.key1

AMDa.key2=c.key2;

这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。

3、在子查询中慎重使用IN或者NOTIN语句，使用where(NOT)exists的效果要好的多。

4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询最好都分解为对数据表的直接查询效果要好一些。

5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。

6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。

四、CPU参数的调整

CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90%以上。如果空闲时间CPU使用率就在90%以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。

使用操作相同命令可以看到CPU的使用情况，一般UNIX操作系统的服务器，可以使用sar_u命令查看CPU的使用率，NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。

数据库管理员可以通过查看v$sysstat数据字典中“CPUusedbythissession”统计项得知ORACLE数据库使用的CPU时间，查看“OSUserlevelCPUtime”统计项得知操作系统用户态下的CPU时间，查看“OSSystemcallCPUtime”统计项得知操作系统系统态下的CPU时间，操作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占操作系统总的CPU时间90%以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。

数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。

出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。

1、数据库管理员可以执行下述语句来查看SQL语句的解析情况：

SELECT*FROMV$SYSSTATWHERENAMEIN

('parsetimecpu','parsetimeelapsed','parsecount(hard)');

这里parsetimecpu是系统服务时间，parsetimeelapsed是响应时间，用户等待时间，waitetime=parsetimeelapsed_parsetimecpu

由此可以得到用户SQL语句平均解析等待时间=waitetime/parsecount。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句

SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREA

ORDERBYPARSE_CALLS;

来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。

2、数据库管理员还可以通过下述语句：

SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA;

查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。

3、数据库管理员可以通过v$system_event数据字典中的“latchfree”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latchfree查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。

五、内存参数的调整

内存参数的调整主要是指ORACLE数据库的系统全局区(SGA)的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。

1、共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句：

select(sum(pins-reloads))/sum(pins)"LibCache"fromv$librarycache;

来查看共享SQL区的使用率。这个使用率应该在90%以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句：

select(sum(gets-getmisses-usage-fixed))/sum(gets)"RowCache"fromv$rowcache;

查看数据字典缓冲区的使用率，这个使用率也应该在90%以上，否则需要增加共享池的大小。

2、数据缓冲区。数据库管理员可以通过下述语句：

SELECTname,valueFROMv$sysstatWHEREnameIN('dbblockgets','consistentgets','physicalreads');

来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。

这个命中率应该在90%以上，否则需要增加数据缓冲区的大小。

3、日志缓冲区。数据库管理员可以通过执行下述语句：

selectname,valuefromv$sysstatwherenamein('redoentries','redologspacerequests');

查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率：

申请失败率=requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。

昆明北大青鸟java培训班转载自网络如有侵权请联系我们感谢您的关注谢谢支持

② 学习如何创建一个简单的存储过程掌握存储过程的基本原理和实践技巧

它可以将一系列的SQL语句封装成一个可重复执行的单元、存储过程是数据库中一种重要的对象、提高数据库的性能和安全性。并给出具体的步骤和注意事项，本文将为您详细介绍如何创建一个简单的存储过程。

1.存储过程是什么？

它们被命名并存储在数据库中、可以像调用函数一样执行和调用，存储过程是一组预定义的SQL语句。

2.存储过程的优势

提高性能、提供数据安全性，存储过程可以减少网络传输开销，简化应用开发等。

3.存储过程的创建步骤

a.创建存储过程的语法格式：CREATEPROCEDUREprocere_name(parameters)ASBEGIN...END

b.编写存储过程的具体逻辑和SQL语句

c.执行CREATEPROCEDURE语句来创建存储过程

4.存储过程参数的使用

a.IN参数：传递值给存储过程

b.OUT参数：从存储过程返回值给调用者

c.INOUT参数：既可以传递值给存储过程，又可以从存储过程返回值给调用者

5.存储过程的异常处理

，保证数据的完整性和一致性，、使用TRY，CATCH块来捕捉和处理存储过程中的异常情况。

6.存储过程的调试方法

a.使用PRINT语句输出调试信息

b.使用SELECT语句查询中间结果

c.使用SQLServerManagementStudio提供的调试功能进行断点调试

7.存储过程的执行和调用

a.执行存储过程的语法：EXECprocere_name

b.调用存储过程并传递参数的语法：EXECprocere_nameparameter_values

8.存储过程的修改和删除

a.修改存储过程的语法：ALTERPROCEDUREprocere_name

b.删除存储过程的语法：DROPPROCEDUREprocere_name

9.存储过程的注意事项

a.使用明确的命名规则来命名存储过程

b.注释存储过程中的重要代码段

c.针对不同的数据库平台，存储过程的语法可能有所不同

10.存储过程的性能优化

a.避免在存储过程中执行耗时长的操作

b.适时使用临时表来优化查询性能

c.避免在存储过程中使用不必要的循环

11.存储过程的安全性考虑

a.对存储过程进行访问控制，限制只有授权用户能够执行

b.避免在存储过程中直接使用用户输入的值，防止SQL注入攻击

12.存储过程的实际应用场景

a.数据库备份和恢复

b.数据库批量处理

c.数据库权限管理

13.存储过程的常见问题和解决方法

a.存储过程执行时间过长：优化查询语句、增加索引等

b.存储过程出现死锁：合理设计事务和锁定策略

c.存储过程返回结果不正确：检查存储过程逻辑和参数传递是否正确

14.存储过程与函数的区别与联系

a.存储过程是用于执行一系列操作的，而函数是用于返回单个值的

b.存储过程可以调用函数，而函数不能直接调用存储过程

15.存储过程的进一步学习资源推荐

帮助读者深入学习和掌握存储过程的更高级技术，推荐一些书籍，在线教程和博客。

您已经了解了如何创建一个简单的存储过程、通过本文的学习，并掌握了存储过程的基本原理和实践技巧。让您更加熟练地应用存储过程来提高数据库的性能和安全性、希望本文能为您提供帮助、存储过程在数据库开发中具有重要作用。

通过实例学习如何编写存储过程

它能够接受参数并返回结果、存储过程是一种在数据库中存储的可重复使用的代码块。我们将学习如何创建一个简单的存储过程，在本文中，并通过一个实例来了解它的用途和编写方法。

段落1什么是存储过程

并存储在数据库中以供反复使用、存储过程是一组预编译的SQL语句，它们被封装在一个命名块中。输出参数以及一系列的SQL语句、它可以包含输入参数，用于执行特定的数据库操作。

段落2为什么使用存储过程

使用存储过程可以提高数据库性能和安全性。减轻了网络负载、存储过程通过减少与数据库的通信次数。并将其封装在数据库中，存储过程还可以实现复杂的业务逻辑，确保数据的安全性和一致性。

段落3如何创建一个简单的存储过程

我们需要在数据库管理系统中选择一个合适的编程语言来编写存储过程。T，PL/SQL，常用的选择包括SQL-SQL等。我们需要定义存储过程的名称，输入参数和输出参数，接下来（如果有的话）。以实现特定的数据库操作，我们可以在存储过程中编写一系列的SQL语句。

段落4存储过程的输入参数和输出参数

用于在执行时传递数据给存储过程、存储过程可以接受输入参数。如整数、字符串，输入参数可以是各种数据类型，日期等。以便将结果返回给调用方，存储过程也可以返回输出参数，同时。

段落5存储过程的控制流程

循环等，存储过程可以包含控制结构，以实现复杂的业务逻辑，如条件判断。我们可以根据不同的条件执行不同的SQL语句、实现更灵活的数据库操作，通过使用这些控制结构。

段落6存储过程的错误处理

我们需要考虑错误处理机制，在编写存储过程时。保证存储过程的健壮性和可靠性、我们可以捕获和处理可能出现的错误、通过使用异常处理语句。

段落7存储过程的优化技巧

我们可以采用一些优化技巧、为了提高存储过程的性能。选择适当的存储过程参数类型等，合理使用索引、避免大量的数据传输。这些优化技巧可以显着提升存储过程的执行效率。

段落8如何调用存储过程

我们需要使用特定的语法来传递参数并获取结果，在调用存储过程时。因此我们需要根据实际情况来选择适合的方法，不同的数据库管理系统可能有不同的调用语法。

段落9存储过程的应用场景

存储过程在实际开发中有广泛的应用场景。数据转换，复杂查询等，它可以用于数据清洗。提高开发效率和数据处理能力，通过使用存储过程、我们可以将这些复杂的操作封装在数据库中。

段落10存储过程的安全性

存储过程可以增加数据库的安全性。我们可以控制用户对数据库的操作范围，通过限制对存储过程的访问权限，并确保数据的安全性和机密性。

段落11存储过程的维护和更新

我们可能需要对存储过程进行维护和更新，随着业务需求的变化。以确保修改后的存储过程不会破坏现有的业务逻辑和数据完整性，我们需要谨慎处理，在进行维护和更新时。

段落12存储过程的调试技巧

我们可能会遇到错误、在编写存储过程时。如打印调试信息，我们可以使用调试技巧，使用断点等，为了排除这些错误。这些技巧可以帮助我们找出问题并进行修复。

段落13存储过程的版本控制

以确保在不同的环境中能够正确地部署和使用，存储过程也需要进行版本控制。并进行合理的版本管理，我们可以跟踪和管理存储过程的变更历史，通过使用版本控制工具。

段落14存储过程的性能监控

我们可以使用性能监控工具来对其进行监控和优化，为了保证存储过程的性能。并根据这些指标进行性能优化，资源占用等指标、通过监控工具、我们可以了解存储过程的执行时间。

段落15

我们了解了存储过程的基本概念和使用方法，通过本文。优化技巧和安全性等方面的知识、并了解了它的应用场景、我们学习了如何创建一个简单的存储过程。为数据库开发和管理工作提供更加高效和可靠的解决方案，通过不断实践和学习，我们可以进一步提升自己的存储过程编写能力。

以及存储过程的使用、本文介绍了如何创建一个简单的存储过程，优化和安全性等方面的知识。并在实际开发中灵活应用，我们可以掌握存储过程编写的基本技巧，通过学习和实践。希望本文对读者在数据库开发和管理方面有所帮助，存储过程是提高数据库性能和安全性的重要工具。

③ 为什么这个存储过程执行的性能这么差

大家都在讨论关于数据库优化方面的东东，刚好参与开发了一个数据仓库方面的项目，以下的一点东西算是数据库优化方面的学习 实战的一些心得体会了，拿出来大家共享。欢迎批评指正阿！

SQL语句：
是对数据库(数据)进行操作的惟一途径；
消耗了70%~90%的数据库资源；独立于程序设计逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低；
可以有不同的写法；易学，难精通。

SQL优化：
固定的SQL书写习惯，相同的查询尽量保持相同，存储过程的效率较高。
应该编写与其格式一致的语句，包括字母的大小写、标点符号、换行的位置等都要一致

ORACLE优化器：
在任何可能的时候都会对表达式进行评估，并且把特定的语法结构转换成等价的结构，这么做的原因是
要么结果表达式能够比源表达式具有更快的速度
要么源表达式只是结果表达式的一个等价语义结构
不同的SQL结构有时具有同样的操作（例如：= ANY (subquery) and IN (subquery)），ORACLE会把他们映射到一个单一的语义结构。

1 常量优化：
常量的计算是在语句被优化时一次性完成，而不是在每次执行时。下面是检索月薪大于2000的的表达式：
sal > 24000/12
sal > 2000
sal*12 > 24000
如果SQL语句包括第一种情况，优化器会简单地把它转变成第二种。
优化器不会简化跨越比较符的表达式，例如第三条语句，鉴于此，应尽量写用常量跟字段比较检索的表达式，而不要将字段置于表达式当中。否则没有办法优化，比如如果sal上有索引，第一和第二就可以使用，第三就难以使用。

2 操作符优化：
优化器把使用LIKE操作符和一个没有通配符的表达式组成的检索表达式转换为一个“=”操作符表达式。
例如：优化器会把表达式ename LIKE 'SMITH'转换为ename = 'SMITH'
优化器只能转换涉及到可变长数据类型的表达式，前一个例子中，如果ENAME字段的类型是CHAR(10)， 那么优化器将不做任何转换。
一般来讲LIKE比较难以优化。

其中：
~~ IN 操作符优化：
优化器把使用IN比较符的检索表达式替换为等价的使用“=”和“OR”操作符的检索表达式。
例如，优化器会把表达式ename IN ('SMITH','KING','JONES')替换为
ename = 'SMITH' OR ename = 'KING' OR ename = 'JONES‘

~~ ANY和SOME 操作符优化:
优化器将跟随值列表的ANY和SOME检索条件用等价的同等操作符和“OR”组成的表达式替换。
例如，优化器将如下所示的第一条语句用第二条语句替换：
sal > ANY (:first_sal, :second_sal)
sal > :first_sal OR sal > :second_sal
优化器将跟随子查询的ANY和SOME检索条件转换成由“EXISTS”和一个相应的子查询组成的检索表达式。
例如，优化器将如下所示的第一条语句用第二条语句替换：
x > ANY (SELECT sal FROM emp WHERE job = 'ANALYST')
EXISTS (SELECT sal FROM emp WHERE job = 'ANALYST' AND x > sal)

~~ ALL操作符优化:
优化器将跟随值列表的ALL操作符用等价的“=”和“AND”组成的表达式替换。例如：
sal > ALL (:first_sal, :second_sal)表达式会被替换为：
sal > :first_sal AND sal > :second_sal
对于跟随子查询的ALL表达式，优化器用ANY和另外一个合适的比较符组成的表达式替换。例如
x > ALL (SELECT sal FROM emp WHERE deptno = 10) 替换为：
NOT (x <= ANY (SELECT sal FROM emp WHERE deptno = 10))
接下来优化器会把第二个表达式适用ANY表达式的转换规则转换为下面的表达式：
NOT EXISTS (SELECT sal FROM emp WHERE deptno = 10 AND x <= sal)

~~ BETWEEN 操作符优化:
优化器总是用“>=”和“<=”比较符来等价的代替BETWEEN操作符。
例如：优化器会把表达式sal BETWEEN 2000 AND 3000用sal >= 2000 AND sal <= 3000来代替。

~~ NOT 操作符优化:
优化器总是试图简化检索条件以消除“NOT”逻辑操作符的影响，这将涉及到“NOT”操作符的消除以及代以相应的比较运算符。
例如，优化器将下面的第一条语句用第二条语句代替：
NOT deptno = (SELECT deptno FROM emp WHERE ename = 'TAYLOR')
deptno <> (SELECT deptno FROM emp WHERE ename = 'TAYLOR')
通常情况下一个含有NOT操作符的语句有很多不同的写法，优化器的转换原则是使“NOT”操作符后边的子句尽可能的简单，即使可能会使结果表达式包含了更多的“NOT”操作符。
例如，优化器将如下所示的第一条语句用第二条语句代替：
NOT (sal < 1000 OR comm IS NULL)
NOT sal < 1000 AND comm IS NOT NULL sal >= 1000 AND comm IS NOT NULL

如何编写高效的SQL:
当然要考虑sql常量的优化和操作符的优化啦，另外，还需要：

1 合理的索引设计：
例：表record有620000行，试看在不同的索引下，下面几个SQL的运行情况：
语句A
SELECT count(*) FROM record
WHERE date >'19991201' and date < '19991214‘ and amount >2000

语句B
SELECT count(*) FROM record
WHERE date >'19990901' and place IN ('BJ','SH')

语句C
SELECT date,sum(amount) FROM record
group by date
1 在date上建有一个非聚集索引
A：(25秒)
B：(27秒)
C：(55秒)
分析：
date上有大量的重复值，在非聚集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。
2 在date上的一个聚集索引
A：（14秒）
B：（14秒）
C：（28秒）
分析：
在聚集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。
3 在place，date，amount上的组合索引
A：（26秒）
C：（27秒）
B：（< 1秒）
分析：
这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。
4 在date，place，amount上的组合索引
A： (< 1秒)
B：（< 1秒）
C：（11秒）
分析：
这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。

总结1
缺省情况下建立的索引是非聚集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，考虑建立聚集索引；
经 常同时存取多列，且每列都含有重复值可考虑建立组合索引；在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员 表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

2 避免使用不兼容的数据类型：
例如float和INt、char和varchar、bINary和varbINary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:
SELECT name FROM employee WHERE salary ＞ 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

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

4 IN和EXISTS：
EXISTS要远比IN的效率高。里面关系到full table scan和range scan。几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
例子：
语句1
SELECT dname, deptno FROM dept
WHERE deptno NOT IN
(SELECT deptno FROM emp);
语句2
SELECT dname, deptno FROM dept
WHERE NOT EXISTS
(SELECT deptno FROM emp
WHERE dept.deptno = emp.deptno);
明显的，2要比1的执行性能好很多
因为1中对emp进行了full table scan,这是很浪费时间的操作。而且1中没有用到emp的INdex，
因为没有WHERE子句。而2中的语句对emp进行的是range scan。

5 IN、OR子句常会使用工作表，使索引失效：
如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。

6 避免或简化排序：
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
索引中不包括一个或几个待排序的列；
group by或order by子句中列的次序与索引的次序不一样；
排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。

7 消除对大型表行数据的顺序存取：
在 嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询 10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄??）和选课表（学号、课程号、成绩）。如果两个 表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的WHERE子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。

8 避免相关子查询：
一个列的标签同时在主查询和WHERE子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

9 避免困难的正规表达式：
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3] >“80”，在WHERE子句中采用了非开始子串，因而这个语句也不会使用索引。

10 不充份的连接条件：
例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况：
SELECT sum(a.amount) FROM account a,card b WHERE a.card_no = b.card_no
（20秒）
将SQL改为：
SELECT sum(a.amount) FROM account a,card b WHERE a.card_no = b.card_no and a.account_no=b.account_no
（< 1秒）
分析：
在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为：
外层表account上的22541页 （外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O
在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：
外层表card上的1944页 （外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O
可见，只有充份的连接条件，真正的最佳方案才会被执行。
多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。
不可优化的WHERE子句
例1
下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢：
SELECT * FROM record WHERE substrINg(card_no,1,4)='5378'
(13秒)
SELECT * FROM record WHERE amount/30< 1000
（11秒）
SELECT * FROM record WHERE convert(char(10),date,112)='19991201'
（10秒）
分析：
WHERE子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成下面这样：
SELECT * FROM record WHERE card_no like '5378%'
（< 1秒）
SELECT * FROM record WHERE amount< 1000*30
（< 1秒）
SELECT * FROM record WHERE date= '1999/12/01'
（< 1秒）

11 存储过程中，采用临时表优化查询：
例
1．从parven表中按vendor_num的次序读数据：
SELECT part_num，vendor_num，price FROM parven ORDER BY vendor_num
INTO temp pv_by_vn
这个语句顺序读parven（50页），写一个临时表（50页），并排序。假定排序的开销为200页，总共是300页。
2．把临时表和vendor表连接，把结果输出到一个临时表，并按part_num排序：
SELECT pv_by_vn，＊ vendor.vendor_num FROM pv_by_vn，vendor
WHERE pv_by_vn.vendor_num=vendor.vendor_num
ORDER BY pv_by_vn.part_num
INTO TMP pvvn_by_pn
DROP TABLE pv_by_vn
这 个查询读取pv_by_vn(50页)，它通过索引存取vendor表1.5万次，但由于按vendor_num次序排列，实际上只是通过索引顺序地读 vendor表（40＋2=42页），输出的表每页约95行，共160页。写并存取这些页引发5＊160=800次的读写，索引共读写892页。
3．把输出和part连接得到最后的结果：
SELECT pvvn_by_pn.＊，part.part_desc FROM pvvn_by_pn，part
WHERE pvvn_by_pn.part_num=part.part_num
DROP TABLE pvvn_by_pn
这样，查询顺序地读pvvn_by_pn(160页)，通过索引读part表1.5万次，由于建有索引，所以实际上进行1772次磁盘读写，优化比例为30∶1。

④ 如何对数据库性能进行优化

1.数据库I/O方面硬件性能

最有可能影响性能的是磁盘和网络吞吐量。解决办法：

• 扩大虚拟内存，并保证有足够可以扩充的空间

• 把数据库服务器上的不必要服务关闭掉

• 把SQL数据库服务器的吞吐量调为最大

2.调整数据库

• 若对该表的查询频率比较高，则建立索引。

• 分区（如MySQL，按时间分区）

• 尽量使用固定长度字段和限制字段长度（如 varchar(10)）优势：
  降低物理存储空间
  提高数据库处理速度
  附带校验数据库是否合法功能

3.使用存储过程

应用程序的实现过程中，能够采用存储过程实现的对数据库的操作尽量通过存储过程来实现。

因为存储过程是存放在数据库服务器上的一次性被设计、编码、测试，并被再次使用，需要执行该任务的应用可以简单地执行存储过程，并且只返回结果集或者数值。

这样不仅可以使程序模块化，同时提高响应速度，减少网络流量，并且通过输入参数接受输入，使得在应用中完成逻辑的一致性实现。

4.SQL语句方面

建立查询条件索引仅仅是提高速度的前提条件，响应速度的提高还依赖于对索引的使用。不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。

• 优化sql语句，减少比较次数

• 限制返回条目数(mysql中使用limit)

5.Java方面

• 尽可能的少创造对象

• 合理摆正系统设计的位置。大量数据操作，和少量数据操作一定是分开的。

• 合理利用内存，有的数据要缓存。让数据流起来，而不是全部读到内存再处理，而是边读取边处理。