首页新闻找找看学习计划

请教大家ORM框架使用中的性能问题

0
悬赏园豆:50 [已解决问题] 解决于 2013-01-14 17:36

公司在做产品平台,数据访问使用的hibernate框架,现在开发也基本成型。但在做性能测试的时候发现一个问题,大数据量下列表分页效率非常低。

比如有个合同单据主表A(ID int,Code varchar(20),CreateTime datetime,USERID int ……) 还有其他字段就不说了,该表每天有增删,还有一张用户表B(UserID int,Name varchar(20) ……),该表增删不多。其中A表数据量100万,ID列自增主键有聚集索引,Code、Createtime和Userid有非聚集索引;B表数据量3万,UserID列主键聚集索引。

第一页的SQL语句大概这样

select top 25 a.code,b.Name from A left join B on A.UserID=b.UserID where a.code like 'TCMM%'  order  by a.createtime desc

如果where条件命中记录数2千左右:单独执行SQL语句时间8ms,10个并发40ms左右,数据库CPU20%。

如果where条件命中记录数2万左右:单独执行SQL语句时间60ms,10个并发150ms左右,数据库CPU90%。

当10个并发时数据库已经没有资源干其他的了,看了一下执行计划createtime排序使用了索引扫描,也就是说随着命中数增加性能直线下降。如果只是真对当前语句优化我试过两个方法,1.A.code中添加包含索引,把createtime添加进去;2.Order by排序改成code。这两个办法性能都非常好,10个并发大概1ms,数据库服务器CPU15%,每秒事务数1万多。

 

其实影响性能的地方很明显createtime做索引扫描,如果只是当前语句优化好办多了,但事实要针对ORM出优化解决方案。

实际情况是这样,

1、排序字段是不固定的,任何一个字段都可能排序。

2、返回字段和where条件也不确定,不一定code做筛选,包含索引用不上

3、左链接表可能有好几个,并且在where中也可能有条件限制

4、当where命中率超过2%时,10个并发用户可以把数据库服务器压死,响应时间4秒左右,每秒事务数只有5个,不能忍受啊(WEB服务器和数据库服务器性能都非常好12颗CPU,32G内存)

 

对于这种情况大家有什么好的解决方案吗? 小弟感激不尽~!!!

问题补充:

方案不好讨论,大家帮忙优化一个SQL语句吧,就是分页生成的两个语句。检索结果命中数2万条。

1、

SELECT TOP 25 (c.F_ID) AS ID_
, (c.F_CODE) AS Code_
, (c.F_CREATE_TIME) AS CreateTime_
, (c.F_NAME) AS Name_
, Dept.F_NAME AS DeptName
FROM
T_TC_CONTRACT c
LEFT OUTER JOIN T_ORG_DEPT Dept
ON c.F_DEPT_ID = Dept.F_DEPT_ID
WHERE
(1 = 1)
AND (c.F_CODE LIKE 'TCMM\_BG\_41%' ESCAPE '\'
AND (Dept.F_DEPT_ID = 1012
OR Dept.F_DEPT_ID = 1011
OR Dept.F_FULL_DEPT_ID LIKE ('1/1011/%'))
)
ORDER BY
c.F_CREATE_TIME DESC
, c.F_ID ASC

2、

SELECT count(*)
FROM
T_TC_CONTRACT c
LEFT OUTER JOIN T_ORG_DEPT Dept
ON c.F_DEPT_ID = Dept.F_DEPT_ID
WHERE
(1 = 1)
AND (c.F_CODE LIKE 'TCMM\_BG\_41%' ESCAPE '\'
AND (Dept.F_DEPT_ID = 1012
OR Dept.F_DEPT_ID = 1011
OR Dept.F_FULL_DEPT_ID LIKE ('1/1011/%')))

 

    其中表 T_TC_CONTRACT中F_ID是自增主键和聚集索引,F_CODE和F_CREATE_TIME上有非聚集索引,其他列没有索引,数据量100万;表 T_ORG_DEPT中F_DEPT_ID上有主键和聚集索引,数据量3万。

    没有并发时语句1执行时间400毫秒,语句2执行时间300毫秒左右。如果10个并发,两个语句执行时间在3秒以上。

     请大家帮忙把10个并发执行时间降到1秒内,可以修改索引结构,感觉主要是count性能比较低,谢谢

卒子的主页 卒子 | 小虾三级 | 园豆:588
提问于:2012-11-16 15:53
< >
分享
最佳答案
0

数据多了 就别用ORM了。直接写SQL语句吧。

收获园豆:20
````` | 专家六级 |园豆:14268 | 2012-11-16 19:09

写SQL也不能解决根本问题吧? 针对固定语句可以优化,但对当前环境还是没有解决方案

卒子 | 园豆:588 (小虾三级) | 2012-11-17 22:23

@卒子: 如果要like就使用lucene来做,如果没有太多的地方是like那么写sql足够解决问题。

````` | 园豆:14268 (专家六级) | 2012-12-02 09:23
其他回答(3)
0

搜索的时候建议使用lucene来做,这样就不怕数据多了

收获园豆:10
az235 | 园豆:8263 (大侠五级) | 2012-11-16 17:30

lucene还没有用过,研究一下看看怎么样

支持(0) 反对(0) 卒子 | 园豆:588 (小虾三级) | 2012-11-17 22:19
0

 这么数据   like  会死人的

收获园豆:10
世界万物 | 园豆:276 (菜鸟二级) | 2012-11-16 17:55

如果命中数据量在0.5%左右就没有问题,但实际使用肯定不会这么少,10%左右应该比较正常

支持(0) 反对(0) 卒子 | 园豆:588 (小虾三级) | 2012-11-17 22:25
0

试试 dapper.net

收获园豆:10
Charleston | 园豆:10 (初学一级) | 2012-11-16 22:00
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册