提升数据库性能可以提升查询速度,优化数据库结构,减少服务器压力等,那么如何优化数据库呢?昆明电脑培训http://www.kmbdqn.cn/来看看下面的文章!
1.数据库I/O方面硬件性能
最有可能影响性能的是磁盘和网络吞吐量。解决办法:
·扩大虚拟内存,并保证有足够可以扩充的空间
·把数据库服务器上的不必要服务关闭掉
·把SQL数据库服务器的吞吐量调为最大
2.调整数据库
·若对该表的查询频率比较高,则建立索引。
·分区(如MySQL,按时间分区)
·尽量使用固定长度字段和限制字段长度(如varchar(10))优势:
降低物理存储空间
提高数据库处理速度
附带校验数据库是否合法功能
3.使用存储过程
应用程序的实现过程中,能够采用存储过程实现的对数据库的 *** 作尽量通过存储过程来实现。
因为存储过程是存放在数据库服务器上的一次性被设计、编码、测试,并被再次使用,需要执行该任务的应用可以简单地执行存储过程,并且只返回结果集或者数值。
这样不仅可以使程序模块化,同时提高响应速度,减少网络流量,并且通过输入参数接受输入,使得在应用中完成逻辑的一致性实现。
4.SQL语句方面
建立查询条件索引仅仅是提高速度的前提条件,响应速度的提高还依赖于对索引的使用。不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。
·优化sql语句,减少比较次数
·限制返回条目数(mysql中使用limit)
提高查询效率首先要想到的就是加索引,那什么是索引呢?MySQL索引的建立对于MySQL的高效运行是很重要的,索引可以大大提高MySQL的检索速度。
打个比方,如果合理的设计且使用索引的MySQL是一辆兰博基尼的话,那么没有设计和使用索引的MySQL就是一个人力三轮车。
索引分单列索引和组合索引。单列索引,即一个索引只包含单个列,一个表可以有多个单列索引,但这不是组合索引。组合索引,即一个索引包含多个列。
创建索引时,你需要确保该索引是应用在 SQL 查询语句的条件(一般作为 WHERE 子句的条件)。
实际上,索引也是一张表,该表保存了主键与索引字段,并指向实体表的记录。
上面都在说使用索引的好处,但过多的使用索引将会造成滥用。因此索引也会有它的缺点:虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATE和DELETE。因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件。
建立索引会占用磁盘空间的索引文件。
如何使用索引呢?
首先索引有窄索引和宽索引两个概念,窄索引是指索引的列数为1~2,宽索引就是说索引的列数大于2。
因为窄索引的效率要高于宽索引,所以能用窄索引就不要使用宽索引。
那么对单字段索引和复合索引应该如何使用?
目录
单字段索引的情况:
复合索引的优势:
两者的比较:
单字段索引的情况:
1.表的主键,外键必须有索引
2.数据量超过300的表应该有索引
3.经常与其他表进行连接的表,在连接字段上应该建立索引
4.经常出现在where字句中的字段,特点是大表的字段,应该建立索引
5.索引应该建在选择性高的字段上
6.索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建立索引
7.尽量用单字段索引代替复合索引,复合索引的建立需要仔细的斟酌
复合索引的优势:
1.单字段索引很少甚至没有
2.复合索引的几个字段经常同时以AND的方式出现在where语句
当where语句中的条件是OR时,索引不起作用。
两者的比较:
以一个sql语句来举例:SELECT * FROM STUDENT WHERE SEX="男" AND SAGE=18
若在sex 和 sage 两个字段分别创建了单字段索引,mysql查询每次只能使用一个索引,虽然对于未添加索引时使用全盘扫描,我们的效率提升了很多,但如果在sex 和 sage两个字段添加复合索引,效率会跟高,如: 创建(sex, age,teacher)的复合索引,那么其实相当于创建了(area,age,teacher)、(area,age)、(area)三个索引,这被称为最佳左前缀特性。
那对于两者优缺点的比较:
1.对于具有2个用and连接条件的语句,且2个列之间的关联度较低的情况下,复合索引有一定优势。
2.对于具有2个用and连接条件的语句,且2个列之间的关联度较高的情况下,复合索引有很大优势。
3.对于具有2个用or连接条件的语句,单索引有一定优势,因为这种情况下复合索引将会导致全表扫描,而前者可以用到indexmerge的优化。
以上就是如何提高查询效率的全部内容,如果有帮助到你的话记得点个关注哟
1、使你的数据库结构规范化,但是不要求一定达到第三范式,为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处,减少被频繁访问的核心表的数量,并在这些核心表上重点优化索引,表结构(尽量紧凑)。典型的核心表是代码表。3、对于统计类应用,如果可能应写成触发器和存储过程,这样就有可能把一个消耗大量时间的统计运算分布到每INSERT,DELETE,或者UPDATE来处理,从而极大提高查询类 *** 作的速度。查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系统资源和时间,所以过多的索引对性能是损害甚至是毫无效果的。5、如果可能,可以利用大数据库对SQL的一些特殊规定来进一步优化,比如查询暗示。6、适当选择硬件,综合考虑CPU,内存,I/O系统的性能,以当前的CPU,内存配置来看,很多数据库系统的瓶颈出在I/O系统上。所以如果有可能,最好使用RAID。当然如果你有足够的财力,可以买更好的服务器,或者搞服务器集群就更利害啦。7、可能的话,尽量使用存储过程,因为存储过程的执行计划可以重复使用,而且不需要象普通由CLIENT提交的SQL那样进行处理和编译。8、检查你的应用程序设计,如果有可能,尽量减少查询次数和在网络上往返的数据。为了获取少量字段而写SELECT * 对性能的损害也比较利害。9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量业务是允许脏读的,在不关键事务中使用脏读,或者读提交,可以大大降低DEADLOCK和进程之间彼此等待的机会,从而把由于互相锁定资源引起的等待降低到最小。不要在事务执行中进行大量计算或者与用户交互的 *** 作,因为事务的执行在要求上是不允许被打断的原子 *** 作(回滚是失败的),所以事务应该多而短小。长事务会锁住很多资源比较长的时间,因此也比较容易导致其他进程对资源的等待和死锁的机会。10、评估你开发系统的关键业务,在很多数据库系统对性能的要求是彼此矛盾的,比如OLTP应用和DSS是不同的。DSS倾向于使用各种索引加快检索速度,而大量的索引对OLTP则是负担。11、不要在应用程序中写怪异的SQL 查询,比如 WHERE money!40000,这样的语句,这种SQL查询,数据库的SQL优化器是无法进行优化的。12、定期维护和管理你的数据库系统,压缩掉那些垃圾空间,很多数据库系统执行类似删除,事务等 *** 作的时候,并不回收无用的物理空间。所以,制定一份合理的数据库维护计划,不要等日志文件或者LOG文件越长越大的时候才去整理数据库。还有很多很多要注意的东西,。。。。。。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)