数据库性能的优化

其他注意事项 
     “水可载舟,亦可覆舟”,索引也一样。索引有助于提高检索性能,但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引,数据库就要做更多的 工作。过多的索引甚至会导致索引碎片。所以说,我们要建立一个“适当”的索引体系,特别是对聚合索引的创建,更应精益求精,以使您的数据库能得到高性能的 发挥。在实际的开发中,会遇到很多意想不到的情况,最好是多测试一些方案,找出哪种方案效率最高、最为有效。

索引就是优化数据库性能的重要一点

一、数据库设计优化

1、不要使用游标。

使用游标不仅占用内存,而且还用不可思议的方式锁定表,它们可以使DBA所能做的一切性能优化等于没做。游标里每执行一次fetch就等于执行一次select。

2、创建适当的索引

每当为一个表添加一个索引,select会更快,可insert和delete却大大变慢,因为创建了维护索引需要许多额外的工作。

(1)采用函数处理的字段不能利用索引

(2)条件内包括了多个本表的字段运算时不能进行索引

3、使用事务

对于一些耗时的操作,使用事务可以达到很好的优化效果。

4、小心死锁

按照一定的次序来访问你的表。如果你先锁住表A,再锁住表B,那么在所有的存储过程中都要按照这个顺序来锁定它们。 如果某个存储过程先锁定表B,再锁定表A,这可能会导致一个死锁。

5、不要打开大的数据集

6、不要使用服务器端游标

与服务器端游标比起来,客户端游标可以减少服务器和网络的系统开销,并且还减少锁定时间。

7、不要忽略同时修改同一记录的问题

有时候,两个用户会同时修改同一记录,这样,后一个修改者修改了前一个修改者的操作,某些更新就会丢失。处理这种情况,创建一个timestamp字段,在写入前检查它,如果允许,就合并修改,如果存在冲突,提示用户。

8、尽量不要使用text数据类型

除非使用text处理一个很大的数据,否则不要使用它。因为它不易于查询,速度慢,用的不好还会浪费大量的空间。一般varchar可以更好的处理数据。

9、避免在索引列上使用计算

where子句中,如果索引列是函数的一部分,优化器将不使用索引而使用全表扫描。例如:

(低效)select ... from [dept] where [sal]*12>25000;

(高效)select ... from [dept] where [sal]>25000/12;

10、不同类型的索引效能是不一样的,应尽可能先使用效能高的

数字类型的索引查找效率高于字符串类型,定长字符串char、nchar的索引效率高于变长字符串varchar、nvarchar的索引。

(低效)select ... from tableName where username=‘张三‘ and age>=21

(高效)select ... from tableName where age>=21 and username=‘张三‘

二、SQL语句优化 

1、不要使用select *

在select中指定所需要的列,将带来的好处:

(1)减少内存耗费和网络的带宽

(2)更安全

(3)给查询优化器机会从索引读取所有需要的列

2、使用参数查询

主要是防止SQL注入,提高安全性。

3、使用exists或not exists代替in或not in

(高效)select * from [emp] where [empno]>0 and exists (select ‘X‘ from [dept] where [dept].[deptno]=[emp].[deptno] and [loc]=‘MELB‘);

(低效)select * from [emp] where [empno]>0 and [deptno] in (select [deptno] from [dept] where [loc]=‘MELB‘);

4、is null或is not null操作

判断字段是否为空一般是不会应用索引的,因为索引不索引空值。不能用null作索引,任何包含null值的列都将不会被包含在索引中。也就是说如果某列存在空值,即使对该列建索引也不会提高性能。任何在where子句中使用is null或is not null的语句优化器都不允许使用索引。

推荐方案:用其他相同功能的操作运算代替,如:a is not null改为a>0或a>‘‘等。

5、<及>操作

大于或小于一般情况不用调整,因为它有索引就会采用索引查找,但有的情况下可以对它进行优化。如一个表有100万记录,那么执行>2与>=3的效果就有很大区别了。

(低效)select * from [emp] where [deptno]>2;

(高效)select * from [emp] where [deptno]>=3;

6、like操作

like操作可以应用通配符查询,里面的通配符组合可能达到几乎是任意的查询,但是如果用不好则会产生性能上的问题,如lide ‘%5400%‘ 这种查询不会引用索引,而like ‘X5400%‘ 则会引用范围索引。

7、where后面的条件顺序影响

where子句后面的条件顺序对大数据量表的查询会产生直接的影响。如:

select * from zl_yhjbqk where dy_dj=‘1KV以下‘ and xh_bz=1;

select * from zl_yhjbqk where dy_dj=1 and dy_dj=‘1KV以下‘;

以上两个查询,两个字段都没进行索引,所以执行的时候都是全表扫描,第一条SQL的dy_dj=‘1KV以下‘条件在记录集内比率为99%,而xh_bz=1的比率只为0.5%,在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较。而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较,以此可以得出第二条SQL的CPU占用率明显比第一条低。

8、用union替换or(适用于索引列)

通常情况下,用union替换where子句中的or将会起到较好的效果。对索引列使用or将造成全表扫描。注意:这个规则只针对多个索引列有效。如果有column没有被索引,查询效率可能会因为你没有选择or而降低。下面的例子中loc_id和region上都有建索引。

(低效)select loc_id,loc_desc,begion from location where loc_id=10 or begion=‘MELBOURNE‘;

(高效)select loc_id,loc_desc,begion from location where loc_id=10

union

select loc_id,loc_desc_begion from location where begion=‘MELBOURNE‘;

9、优化group by

提高group by语句的效率,可以通过将不需要的记录在group by之前过滤掉。

(低效)select [job],avg([sal]) from [emp] group by [job] having job=‘PRESIDENT‘ or job=‘MANAGER‘;

(高效)select [job],avg([sal]) from [emp] where [job]=‘PRESIDENT‘ or job=‘MANAGER‘ group by [job];

10、使用存储过程

可以考虑使用存储过程封装那些复杂的SQL语句或业务逻辑,这样有几个好处:

(1)存储过程的执行计划可以被缓存在内存中较长的时间,减少了重新编译的时间。

(2)存储过程减少了客户端和服务器的繁复交互。

(3)如果程序发布后需要做某些改变你可以直接修改存储过程而不用修改程序,避免需要重新安装部署程序。

11、用sp_configure ‘query governor cost limit‘或者SET QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时,服务器自动取消查询,在查询之前就扼杀掉。SET LOCKTIME设置锁的时间。

12、使用select top或set rowcount来限制操作的行。

13、如果使用了in或or等时发现查询没有走索引,使用显式申明指定索引: SELECT * FROM PersonMember (INDEX = IX_Title) WHERE processid IN (‘男‘,‘女‘)。

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

15、分析select emp_name form employee where salary>3000 在此语句中若salary是Float类型的,则优化器对其进行优化为Convert(float,3000),因为3000是个整数,我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。

三、处理百万级以上数据提高查询速度的方法

1、尽量避免在where子句中使用!=或<>操作符,否则将使引擎放弃使用索引而进行全表扫描。

2、应考虑在where及order by涉及的列上建立索引。

3、尽量避免在where子句中对字段进行null值判断,否则将导致全表扫描。

4、就是避免在where子句中使用or来连接条件,否则将导致全表扫描。

select id from t where num=10 or num=20  改写为

select id from t  where num=10

union all

select id from t where num=20

5、尽量避免使用前置百分号。

select id from t where name like ‘%abc%‘

6、in 和not in也要慎用,很多时候可以用exists和not exists,否则会导致全表扫描。

7、如果在where子句中使用参数,也会导致全表扫描。

select id from t where [email protected]  可以改为强制查询使用索引

select id from t with(index(索引名)) where [email protected]

8、尽量避免在where子句中对字段进行表达式操作,否则将导致全表扫描。

select id from t where num/2=100

应改为:

select id from t where num=100*2

9、尽量避免在where子句中对字段进行函数操作,否则将导致全表扫描。

select id from t where substring(name,1,3)=‘abc‘

应改为:

select id from t where name like ‘abc%‘

10、并不是所有索引对查询都有效,SQL根据表中数据来进行查询优化,当索引列有大量数据重复时,SQL查询可能不会去利用索引。

11、索引并不是越多越好,索引提交了select效率,但是降低了insert和update的效率。一个表的索引数最好不要超过6个。

12、尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。因为引擎在处理查询和连接时会逐个比较字符串中每个字符,而对于数字型而言只需要比较一次就够了。

13、尽可能使用varchar/nvarchar代替char/nchar,因为首先变长字段存储空间小,可以节省存储空间;其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。

14、任何地方都不要使用select *,用具体的字段列表代替*,不要返回用不到的字段。

15、尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就考虑改写。

16、尽量避免大事务操作,提高系统并发能力。

17、利用set rowcount实现高性能的分页。

游标实际上是一种能从包括多条数据记录的结果集中每次提取一条记录的机制。游标充当指针的作用。尽管游标能遍历结果中的所有行,但他一次只指向一行。

概括来讲,SQL的游标是一种临时的数据库对象,即可以用来存放在数据库表中的数据行副本,也可以指向存储在数据库中的数据行的指针。游标提供了在逐行的基础上操作表中数据的方法。

游标的一个常见用途就是保存查询结果,以便以后使用。游标的结果集是由SELECT语句产生,如果处理过程需要重复使用一个记录集,那么创建一次游标而重复使用若干次,比重复查询数据库要快的多。

大部分程序数据设计语言都能使用游标来检索SQL数据库中的数据,在程序中嵌入游标和在程序中嵌入SQL语句相同

时间: 2024-11-09 00:50:13

数据库性能的优化的相关文章

总结五个小技巧定位数据库性能问题

[e良师益友网]数据库的使用会随着业务的和数据的增长变得迟钝,当数据库性能变得越开越糟糕的时候,技术人员往往可以扭转局面,下面为你介绍几个技术人员使用常使用的判别数据库性能问题的方法 1.基础设施纵向升级.投入更多的计算资源是解决问题的通常办法,但这办法实际上并不一定会让性能获得提升.即使扩充了正确的资源池,能被有效利用 的资源数量仍然是有限的.对于承载于物理设备上的数据库而言,添加基础设施具有一定难度,而但虚拟或云托管的数据库则非常容易调配计算资源. 2.横向扩展.一些类似群集化MySQL的数

SQLServer中的页如何影响数据库性能 (转)

无论是哪一个数据库,如果要对数据库的性能进行优化,那么必须要了解数据库内部的存储结构.否则的话,很多数据库的优化工作无法展开.对于对于数据库管理员来说,虽然学习数据库的内存存储结构比较单调,但是却是我们必须攻下的一个堡垒.在SQLServer数据库中,数据页是其存储的最基本单位.系统无论是在保存数据还是在读取数据的时候,都是以页为单位来进行操作的. 一.数据页的基本组成. 如上图所示,是SQLServer数据库中页的主要组成部分.从这个图中可以看出,一个数据页基本上包括三部分内容,分别为标头.数

Mysql数据库性能优化(一)

参考 http://www.jb51.net/article/82254.htm 今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能.这里,我们不会讲过多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库. mysql的性能优化无法一蹴而就,必须一步一步慢慢来,从各个方面

架构设计:系统存储(8)——MySQL数据库性能优化(4)

================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的

数据库性能优化、统计信息与对象统计信息概述收集、扩展统计信息、dbms_stats.get_prefs

数据库性能优化 相关书籍: 1.基于成本的Oracle优化法则 2.Oracle性能诊断艺术 3.基于Oracle的SQL优化 ----------------------------------------------------------------------------------------- 两种优化器: CBO  cost-base optimizer 基于cost 更大适应性/灵活性/10g开始 RBO  rule-base optimizer 基于规则 制定了15条/10g以

SQL Server数据库性能优化之SQL语句篇(转载)

SQL Server数据库性能优化之SQL语句篇 原文地址:http://www.blogjava.net/allen-zhe/archive/2010/07/23/326927.html 期项目需要,做了一段时间的SQL Server性能优化,遇到了一些问题,也积累了一些经验,现总结一下,与君共享.SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能.操作系统的性能,甚至网卡.交换机等.这篇文章主

架构设计:系统存储(9)——MySQL数据库性能优化(5)

=================================== (接上文<架构设计:系统存储(9)--MySQL数据库性能优化(5)>) 4-3-3-3.避免死锁的建议 上一篇文章我们主要介绍了MySQL数据库中锁的基本原理.工作过程和产生死锁的原因.通过上一篇文章的介绍,可以确定我们需要业务系统中尽可能避免死锁的出现.这里为各位读者介绍一些在InnoDB引擎使用过程中减少死锁的建议. 正确使用读操作语句 经过之前文章介绍,我们知道一般的快照读是不会给数据表任何锁的.那么这些快照读操作

ORACLE数据库性能优化之--&gt;内存磁盘

1,内存结构优化概述 1.1 缓冲区 影响数据库运行性能的缓冲区包括可以共享的SGA和服务器进程私有的pga两大类,其中sga又包括共享池.大型池.java池.数据缓冲区.流池.redo log缓冲区. 1.2 自动内存管理 oracle一般采用自动内存管理来管理系统内存,由oracle自动管理和调整数据库实例的内存大小.在自动管理模式下,首先对初始化参数MEMORY_TARGET(目标内存大小)和MEMORY_MAX_TARGET(最大内存大小)进行配置,数据库调整目标内存大小,根据需要不断重

转载:SqlServer数据库性能优化详解

本文转载自:http://blog.csdn.net/andylaudotnet/article/details/1763573 性能调节的目的是通过将网络流通.磁盘 I/O 和 CPU 时间减到最小,使每个查询的响应时间最短并最大限度地提高整个数据库服务器的吞吐量.为达到此目的,需要了解应用程序的需求和数据的逻辑和物理结构,并在相互冲突的数据库使用之间(如联机事务处理 (OLTP) 与决策支持)权衡. 对性能问题的考虑应贯穿于开发阶段的全过程,不应只在最后实现系统时才考虑性能问题.许多使性能得