SQL数据库优化方法

SQL数据库优化方法
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格式。

5、定时对磁盘进行扫描和磁盘整理,减少系统文件错误及减少磁盘碎片,

进行磁盘整理时最好不要使用WINDOWS本般的扫描功能(扫描之前一定要对数据库作异地备份)。

6、可以考虑设置增大磁盘的缓存区,减少对磁盘的读写次数。

7、升级硬件,整机使用更高配置的硬件。或者可以单独增加CPU个数、增

大内存等。

8、提高网速。

3SQL优化

3.1 注释使用

在语句中多写注释,注释不影响SQL语句的执行效率。增加代码的可读性。

3.2 对于事务的使用

尽量使事务处理达到最短,如果事务太长最好按功能将事务分开执行(如:可以让用户在界面上多几步操作)。事务太长很容易造成数据库阻塞,用户操作速度变慢或死机情况。

3.3 对于与数据库的交互

尽量减少与数据库的交互次数。如果在前端程序写有循球访问数据库操作,最好写成将数据一次读到前端再进行处理或者写成存储过程在数据库端直接处理。

3.4 对于SELECT *这样的语句,

不要使用SELECT *这样的语句,而应该使用SELECT table1.column1这样的语句,明确指出要查询的列减少数据的通讯量并且这样的代码可读性好,便于维护。

3.5 尽量避免使用游标

它占用大量的资源。如果需要row-by-row地执行,尽量采用非光标技术,

如:在客户端循环,用临时表,Table变量,用子查询,用Case语句等等。

如果使用了游标,就要尽量避免在游标循环中再进行表连接的操作。

3.6 尽量使用count(1)

count函数只有在统计表中所有行数时使用,而且count(1)比count(*)更有效率。

3.7 IN和EXISTS

EXISTS要远比IN的效率高。里面关系到full table scan和range scan。

几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。

3.8 注意表之间连接的数据类型

避免不同类型数据之间的连接。

3.9 尽量少用视图

对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质:它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时,不要使用指向多个表的视图,直接从表检索或者仅仅包含这个表的视图上读,否则增加了不必要的开销,查询受到干扰。

3.10 没有必要时不要用DISTINCT和ORDER BY

这些动作可以改在客户端执行,它们增加了额外的开销。

3.11 避免相关子查询

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

3.12 代码离数据越近越好

所以优先选择Default,依次为Rules,Triggers, Constraint(约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束),Procedure.这样不

仅维护工作小,编写程序质量高,并且执行的速度快。

3.13 插入大的二进制值到Image列

使用存储过程,千万不要用内嵌Insert来插入。因为这样应用程序首先将二进制值转换成字符串(尺寸是它的两倍),服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法:Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数,这样处理速度明显改善。

3.14 Between在某些时候比IN 速度更快

Between能够更快地根据索引找到范围。用查询优化器可见到差别。

select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一样的。由于in会在比较多次,所以有时会慢些。

3.15 对Where条件字段修饰字段移到右边

任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边。

3.16 在海量查询时尽量少用格式转换。

3.17 IS NULL 与IS NOT NULL

不能用null作索引,任何包含null值的列都将不会被包含在索引中。

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

3.18 建立临时表,

如果一次性插入数据量很大,那么可以使用select into代替create table,避免log,提高速度;如果数据量不大,为了缓和系统表的资源,建议先create table,然后insert。临时表是tempdb数据库实际的表,没有主键、索引,应该避免在临时表中存储大量的数据。

3.19 Where中索引的使用

WHERE条件顺序尽量把索引字段放在前面(主键的唯一性最高),复合索引字段顺序与where条件顺序保持一致。Sql自动查找使用那个索引。

3.20 外键关联的列应该建立索引

(如子表id)主子表单据肯定要建视图,2个表的关联以2个表中的MainID 为关系,所以,需要给子表的MainID单独建索引,这将很大地提高视图的速度。例如Gy_InOutSub中的InoutMainid增加索引。

3.21 注意UNion和`UNion all 的区别

UNION all执行效率高。

3.22 Insert

Insert into 表values()

应该为

Insert into 表(字段) values()

3.23 order by语句

ORDER BY语句决定了如何将返回的查询结果排序。Order by语句对要排序的列没有什么特别的限制,也可以将函数加入列中(象联接或者附加等)。任何在Order by语句的非索引项或者有计算表达式都将降低查询速度。

仔细检查order by语句以找出非索引项或者表达式,它们会降低性能。

解决这个问题的办法就是重写order by语句以使用索引,也可以为所使用的列建立另外一个索引,同时应绝对避免在order by子句中使用表达式。

3.24 技巧用例

3.2

4.1Sql语句执行时间测试

GreenPlum的SQL优化方案

GreenPlumn的SQL语句查询优化 数据库查询预准备 1. VACUUM ?vacuum只是简单的回收空间且令其可以再次使用,没有请求排它锁,仍旧可以对表读写 ?vacuum full执行更广泛的处理,包括跨块移动行,以便把表压缩至使用最少的磁盘块数目存储。相对vacuum要慢,而且会请求排它锁。 ?定期执行:在日常维护中,需要对数据字典定期执行vacuum,可以每天在数据库空闲的时候进行。然后每隔一段较长时间(两三个月)对系统表执行一次vacuum full,这个操作需要停机,比较耗时,大表可能耗时几个小时。 ?reindex:执行vacuum之后,最好对表上的索引进行重建 2. ANALYZE ?命令:analyze [talbe [(column,..)]] ?收集表内容的统计信息,以优化执行计划。如创建索引后,执行此命令,对于随即查询将会利用索引。 ?自动统计信息收集 ?在postgresql.conf中有控制自动收集的参数gp_autostats_mode设置,gp_autostats_mode三个值:none、no_change、on_no_stats(默认) o none:禁止收集统计信息 o on change:当一条DML执行后影响的行数超过 gp_autostats_on_change_threshold参数指定的值时,会执行完这条DML后再 自动执行一个analyze 的操作来收集表的统计信息。 o no_no_stats:当使用create talbe as select 、insert 、copy时,如果在目标表中没有收集过统计信息,那么会自动执行analyze 来收集这张表的信息。gp 默认使用on_no_stats,对数据库的消耗比较小,但是对于不断变更的表,数 据库在第一次收集统计信息之后就不会再收集了。需要人为定时执行 analyze.

sql语句(mysql优化)绝对经典

sql语句(mysql优化)绝对经典 误区1:count(1)和count(primary_key) 优于count(*) 很多人为了统计记录条数,就使用count(1) 和count(primary_key) 而不是count(*) ,他们认为这样性能更好,其实这是一个误区。对于有些场景,这样做可能性能会更差,应为数据库对count(*) 计数操作做了一些特别的优化。 误区2:count(column) 和count(*) 是一样的 这个误区甚至在很多的资深工程师或者是DBA 中都普遍存在,很多人都会认为这是理所当然的。实际上,count(column) 和count(*) 是一个完全不一样的操作,所代表的意义也完全不一样。count(column) 是表示结果集中有多少个column字段不为空的记录,count(*) 是表示整个结果集有多少条记录 误区3:select a,b from … 比select a,b,c from …可以让数据库访问更少的数据量 这个误区主要存在于大量的开发人员中,主要原因是对数据库的存储原理不是太了解。实际上,大多数关系型数据库都是按照行(row)的方式存储,而数据存取操作都是以一个固定大小的IO单元(被称作block 或者page)为单位,一般为4KB,8KB… 大多数时候,每个IO单元中存储了多行,每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以,我们是取一个字段还是多个字段,实际上数据库在表中需要访问的数据量其实是一样的。当然,也有例外情况,那就是我们的这个查询在索引中就可以完成,也就是说当只取a,b两个字段的时候,不需要回表,而c这个字段不在使用的索引中,需要回表取得其数据。在这样的情况下,二者的IO量会有较大差异。(覆盖索引) 误区4:order by 一定需要排序操作 我们知道索引数据实际上是有序的,如果我们的需要的数据和某个索引的顺序一致,而且我们的查询又通过这个索引来执行,那么数据库一般会省略排序操作,而直接将数据返回,因为数据库知道数据已经满足我们的排序需求了。实际上,利用索引来优化有排序需求的SQL,是一个非常重要的优化手段。延伸阅读:MySQL ORDER BY 的实现分析,MySQL 中GROUP BY 基本实现原理以及MySQL DISTINCT 的基本实现原理。(order by null)

数据库及SQL代码优化方案

1.1、数据库及SQL代码优化方案 (1)每周检查统计信息是否及时更新。 (2)每周检查各索引是否有效。 (3)每周检查分区是否正确。 (4)每周检查执行计划是否正确。 (5)每天检查RAC和ASM是否正常运行。 (6)每天检查相关日志是否正常备份。 (7)每天检查相关文件系统和表空间的占用率是否在国家税务总局规定的阀值以下。 (8)在每月申报高峰等业务繁忙期采样并找出消耗I/O资源和CPU资源较多的SQL语句。 (9)分析上述SQL语句,与软件服务商充分沟通后,提出优化建议。 (10)在每月申报高峰期每隔15分钟检查一次数据库连接数,发现异常及时处理。 1.1.1、系统数据库索引、表分区和对象优化方案 数据库对象的优化主要包括:表、索引和sequence等对象,通过优化对象参数、调整对象属性(例如分区表、分区索引、反转索引等等)等方法来实现对数据库对象的优化改造。 1.1.1.1表和索引并行参数优化 数据库的表和索引的并行参数值的设置对相关的sql语句的执行计划会造成影响,表和索引的degree值大于1,执行计划就偏向于使用全表和全索引扫描,另外如果并行参数值过大,短时间内也会对主机和数据库的资源造成很大的压力,因此在oltp的数据库下建议将表和索引的degree值设为1。 1.1.1.2热点大表的分区改造 对访问量很大、表的记录数很多、存在热块争用的表,可以考虑对表和索引进行适当的分区改造,分散访问压力,提高数据访问的性能。 对以下表的记录数超过1000万并且记录数持续增长的大表,建议进行分区

改造(地区+时间): 1.1.1.3分区索引的清理 对最近30天数据库分区索引访问情况进行统计,对访问次数为0的分区索引和应用部门进行确认,若确认为多余的索引,建议进行删除清理。 1.1.1.4Sequence序列优化 加大sequence 的 cache,并使用noorder选项。在RAC中经常会遇到SQ 锁等待,这是因为在RAC环境下,sequence也成为全局性的了,不同节点要生成序列号,就会产生对sequence资源的争用。而目前大多数系统中,sequence 大多数被作为主键发生器来使用,使用的频率十分高,在RAC环境中,需要设置较大的 sequence cache,否则会造成较为严重的争用,从而影响业务。 1.1.2、SQL硬解析优化方案 1.1. 2.1相关知识点介绍 1.1. 2.1.1Oracle的硬解析和软解析 Oracle对sql的处理过程:当发出一条sql语句交付Oracle,在执行和获取结果前,Oracle对此sql将进行几个步骤的处理过程: 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check) 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。 3、对sql语句进行解析(prase) 利用内部算法对sql进行解析,生成解析树(parse tree)及执行计划(execution plan)。 4、执行sql,返回结果(execute and return) 其中,软、硬解析就发生在第三个过程里。 Oracle利用内部的hash算法来取得该sql的hash值,然后在library cache

大数据库优化(SQLServer)

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

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格式。

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分离

sql优化方案讲解

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

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

SQL2019系统性能优化解决方案共12页文档

SQL Server 系统性能调优解决方案 前言 近几年,医药流通市场经历了激烈的震荡,导致行业逐步成熟和企业的快速变革,差异化经营成为众多医药流通的竞争选择。时空产品在中国医药流通企业的发展过程中得到了广泛且深入应用,大量的客户化开发和定制支撑了企业管理中横向和纵向的变化,很好的适应了企业在发展过程中不断变化的需求。 对于数据库管理系统的使用,很多用户都面临着一个很棘手的问题:系统效率下降。产生效率下降的因素是多方面: 1.硬件问题 2.软件问题 3.实施问题 正因为产生效率下降的因素很多,所以如何去查找原因成为我们首要关注的问题,时空公司也处在积极探索过程中。时空公司在解决一些客户问题的过程中积累了一些方法和思路,归纳总结后呈现给体系内的技术人员,本方案就系统效率调整所必需的基础知识、方法、技巧等几个方面进行阐述,从而让技术人员能够快速定位问题,解决问题,为合作伙伴提供优质,快捷的服务。 索引简介 索引是根据数据库表中一个或多个列的值进行排序的结构。索引提供指针以指向存储在表中指定列的数据值,然后根据指定的排序次序排列这些指针。数据库使用索引的方式与使用书的目录很相似,通过搜索索引找到特定的值,然后跟随指针到达包含该值的行。 索引键:用于创建索引的列。 索引类型 ?聚集索引: 聚集索引基于数据行的键值在表内排序和存储这些数据行。由于数据行按基于聚集索引键的排序次序存储,因此聚集索引对查找行很有效。每个表只能有一个聚集索引,因为数据行本身只能按一个顺序存储。数据行本身构成聚集索引的最低级别(叶子节点)。只有当表包含聚集索引时,表内的数据行才按排序次序存储。如果表没有聚集索引,则其数据行按堆集方式存储。 聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后,便可以确保包含后续索引值的行在物理相邻。例如:如果应用程序执行的一个查询经常检索某一日期范围内的记录,则使用聚集索引可以迅速找到包含开始日期的行,然后检索表中所有相邻的行,直到到达结束日期。这样有助于提高此类查询的性能。同样,如果对从表中检索的数据进行排序时经常要用到某一列,则可以将该表在该列上聚集(物理排序),避免每次查询该列时都进行排序,从而节省成本。 ?非聚集索引 非聚集索引具有完全独立于数据行的结构。非聚集索引的最低行包含非聚集索引的键值,并且每个键值项都有指针指向包含该键值的数据行。数据行不按基于非聚集键的次序存储。如

优化 SQL SELECT 语句性能的 6 个简单技巧

SELECT语句的性能调优有时是一个非常耗时的任务,在我看来它遵循帕累托原则。20%的努力很可能会给你带来80%的性能提升,而为了获得另外20%的性能提升你可能需要花费80%的时间。除非你在金星工作,那里的每一天都等于地球上的243天,否则交付期限很有可能使你没有足够的时间来调优SQL查询。 根据我多年编写和运行SQL语句的经验,我开始开发一个检查列表,当我试图提高查询性能时供我参考。在进行查询计划和阅读我使用的数据库文档之前,我会参考其中的内容,数据库文档有时会很复杂。我的检查列表绝对说不上全面或科学,它更像是一个保守计算,但我可以说,遵循这些简单的步骤大部分时间我确实能得到性能提升。检查列表如下。 检查索引 在SQL语句的WHERE和JOIN部分中用到的所有字段上,都应该加上索引。进行这个3分钟SQL性能测试。不管你的成绩如何,一定要阅读那些带有信息的结果。 限制工作数据集的大小 检查那些SELECT语句中用到的表,看看你是否可以应用WHERE子句进行过滤。一个典型的例子是,当表中只有几千行记录时,一个查询能够很好地执行。但随着应用程序的成长,查询慢了下来。解决方案或许非常简单,限制查询来查看当前月的数据即可。 当你的查询语句带有子查询时,注意在子查询的内部语句上使用过滤,而不是在外部语句上。 只选择你需要的字段 额外的字段通常会增加返回数据的纹理,从而导致更多的数据被返回到SQL客户端。另外: •使用带有报告和分析功能的应用程序时,有时报告性能低是因为报告工具必须对收到的、带有详细形式的数据做聚合操作。 •偶尔查询也可能运行地足够快,但你的问题可能是一个网络相关的问题,因为大量的详细数据通过网络发送到报告服务器。 •当使用一个面向列的DBMS时,只有你选择的列会从磁盘读取。在你的查询中包含的列越少,IO开销就越小。 移除不必要的表 移除不必要的表的原因,和移除查询语句中不需要的字段的原因一致。 编写SQL语句是一个过程,通常需要大量编写和测试SQL语句的迭代过程。在开发过程中,你可能将表添加到查询中,而这对于SQL代码返回的数据可能不会有任何影响。一旦SQL运行正确,我发现许多人不会回顾他们的脚本,不会删除那些对最终的返回数据没有任何影响和作用的表。通过移除与那些不必要表的JOINS操作,你减少了大量数据库必须执行的流程。有时,就像移除列一样,你会发现你减少的数据又通过数据库返回来了。 移除外部连接查询 这说起来容易做起来难,它取决于改变表的内容有多大的影响。一个解决办法是通过在两个表的行中放置占位符来删除OUTER JOINS操作。假设你有以下的表,它们通过定义OUTER JOINS来确保返回所有的数据: customer_idcustomer_name 1John Doe 2Mary Jane 3Peter Pan 4Joe Soap

Oracle SQL性能优化方法研究

Oracle SQL性能优化方法探讨 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访问Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序. (6) 7SELECT子句中幸免使用’*’ (6) 8减少访问数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访问 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14计算记录条数 (9) 15用Where子句替换HAVING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11)

18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)

1综述 ORACLE数据库的性能调整是个重要,却又有难度的话题,如何有效地进行调整,需要通过反反复复的过程。在数据库建立时,就能依照顾用的需要合理设计分配表空间以及存储参数、内存使用初始化参数,对以后的数据库性能有专门大的益处,建立好后,又需要在应用中不断进行应用程序的优化和调整,这需要在大量的实践工作中不断地积存经验,从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整,来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表,能够考虑建立分区以提高操作效率。建

SQL数据库查询优化

一、实验目的 1.熟悉查询查询处理的过程; 2.掌握查询优化的概念,理解查询优化的必要性; 3.了解数据库的查询计划; 4.掌握查询代价的分析方法,并且能通过配置参数或者修改SQL语句来降低 查询代价。 二、实验环境 SQL Server 三、实验学时 2学时 四、实验要求 1)求选修了00002号课程的学生姓名。用SQL表达: SELECT Student.Sname FROM Student,SC WHERE Student.Sno=SC.Sno AND https://www.360docs.net/doc/1218947920.html,o=‘00002’ 2)三种实现方法: Q1=πSname(σStudent.Sno=SC.Sno∧https://www.360docs.net/doc/1218947920.html,o='2' (Student×SC)) Q2=πSname(σhttps://www.360docs.net/doc/1218947920.html,o='2' (Student SC)) Q3=πSname(Student σhttps://www.360docs.net/doc/1218947920.html,o='2'(SC)) 3)要求:本实验旨在说明查询优化的必要性,只要求把法一Q1与法二Q2和法三 Q3比较,从而说明查询优化的重要性 五、实验内容及步骤 (一)实验数据的准备 -- 1.创建数据库 create database stu_optimization ON ( NAME = stu_opti, FILENAME = 'E:\stu_opti\stu_opti.mdf', SIZE = 100, MAXSIZE = 500, FILEGROWTH = 10 ) LOG ON ( NAME = 'stu_opti_log', FILENAME = 'E:\stu_opti\stu_opti_log.ldf', SIZE = 50MB,

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

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

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

SQL优化技巧之DISTINCT去重

SQL优化技巧之DISTINCT去重 单列查询在数据库表中,每个表都包含若干列信息。用户在查询表中的记录时,大多数情况下只是关心表的一-列或者几列的信息。在SQL中,查询表中某- -列(字段)信息的语法可表示如下。SELECT column FROM table_ name_ name SELECT关键词指明了要查询字段名称(column),FROM关键词指明了要获取字段信息 地表的名字。 在SQL语言中,SQL关键词对大小写不敏感,所以对SELECT关键词来说,注意SELECT、select 或者Seleet 都是一样的;然而对于表名或者列名来说,可能对大小写敏感,这取决于数据库的DBMS。

使用DISTINCT去除重复信息在查询中,我们经常需要去除查询结果中的重复信息。例如,一张学生成绩表,其字段包含学生姓名、选修课程和课程成绩3个字段。如果用户想要查询这张表中包含的所有学生的姓名信息,由于同-学生可能有多门选修课,同-学生在该表中就有多条记录,那么查询的姓名字段就会有多个重复值,显然不能很好满足用户的需求。在SELECT 子句中,我们通过指明DISTINCT关键字,可以去除列中的重复信息。语法如下。SELECT DISTINCT column FROM table_ name_ name

DISTINCT关键字去除的是SELECT 子句查询的列,即column的重复信息。如果说明SELECT子句查询的列为多列,那么只有这些列的信息同时重复的记录才能被去除。 使用DISTINCT去除重复信息在TEACHER表中查询所有教师的姓名信息(TNAME),对于重复的姓名只显示一个。示例代码如下。SELECT DISTINCT TNAME FROM TEACHER

SQLServer数据查询的优化方法

SQLServer数据查询的优化方法聂文燕 摘要:SQLServer是一种功能强大的数据库管理系统,许多数据库应用系统都是以它作为后台数据库。本文在分析影响SQLSERVER数据查询效率的因素的基础上,提出了几种优化数据查询的方法。 关键词:SQLServer,数据,查询,优化 一、引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统,它是一个全面的、集成的、端到端的数据解决方案,为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前,许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难,但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践,由于初期的数据库中表的记录数比较少,性能不会有太大问题,但数据积累到一定程度,达到数百万甚至上千万条,全面扫描一次往往需要数十分钟,甚至数小时。20%的代码用去了80%的时间,这是程序设计中的一个著名定律,在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略,往往可以使查询时间降为几分钟。而且我们知道,目前数据库系统应用中,查询操作占了绝大多数,查询优化成为数据库性能优化最为重要的手段之一。 二、影响查询效率的因素 SQLServer处理查询计划的过程是这样的:在做完查询语句的词法、语法检查之后,将语句提交给SQLServer的查询优化器,查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接,并生成若干执行计划,然后通过分析执行开销来评估每个执行计划,从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划,然后在合适的时间提交给系统处理执行,最后将执行结果返回给用户。所以,SQLServer中影响查询效率的因素主要有以下几种:1.没有索引或者没有用到索引。索引是数据库中重要的数据结构,使用索引的目的是避免全表扫描,减少磁盘I/O,以加快查询速度。 2.没有创建计算列导致查询不优化。 3.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)。 4.返回了不必要的行和列。 5.查询语句不好,没有优化。其中包括:查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 三、SQLServer数据查询优化方法 3.1建立合适的索引索引是数据库中重要的数据结构,它的根本目的就是为了提高查询效率。当根据索引码的值搜索数据时,索引提供了对数据的快速访问。事实上,没有索引,数据库也能根据SELECT语句成功地检索到结果,但随着表变得越来越大,使用“适当”的索引的效果就越来越明显。索引的使用要恰到好处,其使用原则有: (1)对于基本表,不宜建立过多的索引; (2)对于那些查询频度高,实时性要求高的数据一定要建立索引,而对于其他的数据不考虑建立索引; (3)在经常进行连接,但是没有指定为外键的列上建立索引; (4)在频繁进行排序或分组(即进行groupby或orderby操作)的列上建立索引;

Oracle_SQL性能优化技巧大总结

(1)选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. (2) WHERE子句中的连接顺序.: ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE 子句的末尾. (3) SELECT子句中避免使用 * : ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 (4)减少访问数据库的次数: ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等; (5)在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 (6)使用DECODE函数来减少处理时间: 使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表. (7)整合简单,无关联的数据库访问: 如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系) (8)删除重复记录: 最高效的删除重复记录方法 ( 因为使用了ROWID)例子: DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)FROM EMP X WHERE X.EMP_NO = E.EMP_NO); (9)用TRUNCATE替代DELETE: 当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. 译者按: TRUNCATE只在删除全表适 用,TRUNCATE是DDL不是DML) (10)尽量多使用COMMIT: 只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求

整理的数据库查询(SQL)效率分析、优化、注意事项

目录 一、关于SQL查询效率,100w数据,查询只要1秒。 (2) 二、SQL提高查询效率注意事项 (4) 三、提高SQL查询效率(要点与技巧) (9) 四、建立索引与不建立索引的一个查询效率分析: (10) 五、如何提高SQL语言的查询效率 (11) 六、使用SQL语句时应注意以下几点 (13) 七、ORACAL中的应用案例分析 (14)

一、关于SQL查询效率,100w数据,查询只要1秒。 ●机器情况:p4: 2.4 ●内存:1 G ●Os:windows 2003 ●数据库:ms sql server 2000 ●目的:查询性能测试,比较两种查询的性能 SQL查询效率step by step: step 1. -- 建表 create table t_userinfo ( userid int identity(1,1) primary key nonclustered, nick varchar(50) not null default '', classid int not null default 0, writetime datetime not null default getdate() ) go -- 建索引 create clustered index ix_userinfo_classid on t_userinfo(classid) go step 2. --插入数据,耗时08:27 ,需要耐心等待 declare @i int declare @k int declare @nick varchar(10) set @i = 1 while @i<1000000 begin set @k = @i % 10 set @nick = convert(varchar,@i) insert into t_userinfo(nick,classid,writetime) values(@nick,@k,getdate()) set @i = @i + 1

PLSQL程序优化和性能分析方法要点

1.前言 1.1目的 性能测试是测试中比较重要的工作,性能测试应分为压力的测试和性能的测试,其中性能问题中绝大部分都是由于程序编写的不合理、不规范造成的。本文档说明了程序中常见的不优化的脚本编写,导致的性能问题,并且在也描述了怎样去跟踪和解决程序上的性能问题的方法。 在最后一章里面描述了做一个白盒测试工具测试性能问题的设计思想。 1.2文档说明 本文档只说明PLSQL 编写的优化问题,不包括ORACLE本身的性能优化(内存SGA、系统参数、表空间等)、操作系统的性能问题和硬件的性能问题。对于PLSQL程序优化方面的内容有很多,本文档列出在我们实际工作中一些常见的情况。本文档难免有不正确的地方,也需要大家给予指正。 本文档举例说明的问题语句不是实际程序中真正存在的,只是让大家能看起来更容易理解,但这些语句也不代表在我们程序中其他部分语句不存在这些问题。 举例说明中的语句采用的是社保核心平台的数据字典,在举例描述中没有标明表名和字 段名的含义,还需单独参考。 1.4参考资料 编号资料名称作者日期出版单位

2.PLSQL程序优化原则 2.1导致性能问题的内在原因 导致系统性能出现问题从系统底层分析也就是如下几个原因: ●CPU 占用率过高,资源争用导致等待 ●内存使用率过高,内存不足需要磁盘虚拟内存 ●IO 占用率过高,磁盘访问需要等待 2.2PLSQL优化的核心思想 PLSQL优化实际上就是避免出现“导致性能问题的内在原因”,实际上编写程序,以及性能问题跟踪应该本着这个核心思想去考虑和解决问题。 ● PLSQL 程序占用CPU的情况 ?系统解析SQL语句执行,会消耗CPU的使用 ?运算(计算)会消耗CPU的使用 ● PLSQL 程序占用内存的情况 ?读写数据都需要访问内存 ?内存不足时,也会使用磁盘 ● PLSQL 程序增大IO的情况 ?读写数据都需要访问磁盘IO ?读取的数据越多,IO就越大 大家都知道CPU现在都很高,计算速度非常快;访问内存的速度也很快;但磁盘的访问相对前两个相比速度就差的非常大了,因此PLSQL 性能优化的重点也就是减少IO的瓶颈,换句话说就是尽量减少IO的访问。 性能的优先级CPU->内存->IO,影响性能的因素依次递增。根据上面的分析,PLSQL 优化的核心思想为: 1.避免过多复杂的SQL 脚本,减少系统的解析过程 2.避免过多的无用的计算,例如:死循环 3.避免浪费内存空间没有必要的SQL脚本,导致内存不足 4.内存中计算和访问速度很快 5.尽可能的减少磁盘的访问的数据量,该原则是PLSQL 优化中重要思想。 6.尽可能的减少磁盘的访问的次数,该原则是PLSQL优化中重要思想。 下面的章节具体介绍常见影响性能的SQL 语句情况。 2.3ORACLE优化器 ORACLE的优化器:

相关文档
最新文档