浅谈数据库优化方案

春季是一个富有生命力季节,也是一个美丽、神奇,充满希望季节。柳树枝条向下垂着,就似一条条线挂树上。春季景色十分美丽,就似一幅栩栩如生画。

本文为大家分享了数据库优化方案,供大家参考,具体内容如下

1. 利用表分区
分区将数据在物理上分隔开,不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样,当对这个表进行查询时,只需要在表分区中进行扫描,而不必进行全表扫描,明显缩短了查询时间,另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O,一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。对数据量大的时时表可采取此方法。可按月自动建表分区。

2. 别名的使用
别名是大型数据库的应用技巧,就是表名、列名在查询中以一个字母为别名,查询速度要比建连接表快1.5倍。

3. 索引Index的优化设计
索引可以大大加快数据库的查询速度。但是并不是所有的表都需要建立索引,只针对大数据量的表建立索引就好。
缺点:
1.创建索引和维护索引要耗费时间,这种时间随着数据量的增加而增加。
2.索引需要占物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,那么需要的空间就会更大。
3.当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度。
索引需要维护:为了维护系统性能,索引在创建之后,由于频繁地对数据进行增加、删除、修改等操作使得索引页发生碎块,因此,必须对索引进行维护。
4. 物化视图(索引视图)

一般的视图是虚拟的,而物化视图是实实在在的数据区域,是要占据存储空间的,另外系统刷新物化视图也需要耗费一定的资源,但是它却换来了效率和灵活性。
索引视图更适合在OLAP(读取较多,更新较少)的数据库中使用,不适合在OLTP(记录即时的增、删、改、查)的数据库中使用 。

物化视图的注意事项:
1.对于复杂而高消耗的查询,如果使用频繁,应建成物化视图。
2.物化视图是一种典型的以空间换时间的性能优化方式。
3.对于更新频繁的表慎用物化视图。
4.选择合适的刷新方式。

普通视图和物化视图的区别:
普通视图和物化视图根本就不是一个东西,普通视图是不存储任何数据的,在查询中是转换为对应定义的SQL去查询,而物化视图是将数据转换为一个表,实际存储着数据,这样查询数据,就不用关联一大堆表,如果表很大的话,会在临时表空间内做大量的操作。
普通视图的三个特征:
1).简化设计,方便,清晰编码。视图并不是提高性能的,它的存在只会降低性能(例如我们关联两个视图,一个视图关联6个表,另一个视图关联7个表)。
2).安全,在授权给其他用户或者查看角度,多个表关联只允许查看,不允许修改。
3.从不同的角度看不同的维度,视图可以划分维度和权限,并使多个维度的综合,也就是你要什么就可以从不同的角度看,而表是一个实体的而已,一般维度较少。

5. 死锁与阻塞
1).对于需要频繁更新的数据,尽量避免放在长事务中,以免导致连锁反应。
2).不是迫不得已,最好不要在数据库锁机制外再加自己设计的锁。
3).减少事务大小,及时提交事务。
4).尽量避免跨数据库的分布式事务,因为环境的复杂性,很容易导致阻塞。
5).慎用位图索引,更新时容易导致死锁。

6.减少IO与网络传输次数
1).尽量用较少的数据库请求,获取到需要的数据,能一次性取出的不分多次取出。
2).对于频繁操作数据库的批量操作,应采用存储过程,减少不必要的网络传输。

到此这篇关于浅谈数据库优化方案就介绍到这了。穿过层层叠叠的流离时光,越过跌跌荡荡的万水千山,我一直走,一直走,来到你的面前,自此,驻足,沦落。早安!更多相关浅谈数据库优化方案内容请查看相关栏目,小编编辑不易,再次感谢大家的支持!

您可能有感兴趣的文章
浅谈一次与sql注入&webshell的美丽“邂逅”

浅谈sqlserver下float的不确定性

浅谈SQLServer交叉联接内部联接