认识达内从这里开始

数据库性能问题是软件运维程序员需要长期关注的一个问题，而本文我们就通过案例分析来简单了解一下，数据库性能问题与优化方法分享。

一、问题的提出

随着系统业务数据量的不断增长,使用用户的不断增加,项目组越来越频繁收到用户反馈的性能问题,主要是以下几个方面的问题:

1.系统使用高峰期比如周一和月初,用户反馈系统登陆不了,菜单响应和操作缓慢等问题;

2.客户查询功能响应缓慢,一个4000条数据的查询时间超过N分钟;

3.客户增量保存功能操作失败,有些时候增量保存的线程跑了1个小时还没成功保存,结果是用户数据丢失(后台同步处理);

4.客户操作后死机

5.管理员反馈报表查询响应不了甚至报系统错误

经过对系统的监测和分析,监测到的问题如下:

1.数据库连接占满,事务等待超时或死锁

2.数据库服务器停止,事务日志占满,报磁盘空间不足的错误

3.后台日志显示数据库语句堆,排序堆不足

4.后台日志显示缓冲池中无页面可用

二、解决思路

系统的核心业务数据是百万级别的数据,以及千万级别的日志数据:

既是一个OLTP系统,又是一个OLAP系统;任务流程处理这块都是一些大事务和并发多的事务,而任务分析这块是实时进行大数据量超复杂的统计运算;这些地方就是系统的性能瓶颈;

鉴于此,我们从SQL语句,应用程序逻辑,数据库,数据归档,部署方式等多个层面进行系统的性能优化,优化的重点是减少事务并发,保证稀有资源的合理利用;

a)系统存在很多树结构数据,比如项目树,WBS,对这些数据进行查询的SQL进行优化,分析发现很多递归SQL在递归层次深,数据量大的情况下,性能问题突出,我们采取的办法是:

尽量使用视图;

将查询条件从SQL语句的外层移到内层子查询,减少数据查询量;

报表SQL允许脏读,以防大面积的关键数据表行锁升级为表锁;

b)系统有很多一对多特别是多对多的表关联查询,比如任务表和日志填报表;分析发现很多地方就用一个超大的SQL查询任务和日志数据,这样查询的结果冗余量大,我们采取的办法是:

拆分成多个SQL进行查询;

c)很多SQL中包含in函数,而且in的子查询语句的结果集不确定,可能上千上万,这种SQL导致数据库后台报语句堆不足的错误,我们采取的优化办法是:

用关联查询替代in函数;

用or语句替代in函数;

d)整理出大数据量查询的SQL语句,找出关联查询的条件,根据索引原则,增加数据库索引;

e)有不少报表统计SQL语句直接处理的大数据量的复杂运算,导致占用大量的数据库资源,我们采取的优化办法是:

SQL语句用来查询数据,而运算统计的部分交给应用服务器处理;

采用静态报表,晚上统计出数据,白天就可以查询统计后的结果数据;

f)分析发现有些SQL语句类似”select*…”,这些地方全部将*号替换成具体的列;

还有些SQL返回的结果集数量是可知的，这些地方使用FETCHFIRSTnROWSONLY参数

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。