SQL语句优化,效率提高

peng2739956 2018-06-12 06:00:45

SELECT DrawID, KindID, ServerID, TableID, UserCount, AndroidCount, Waste, Revenue, UserMedal, StartTime, ConcludeTime, InsertTime, KindName, ServerName,
sum(Score) AS Score, max(BackScore) AS BackScore, BackInsureScore, gameid, accounts, nickname, lastlogonip, LastLogonType, userID
FROM (SELECT A.DrawID, A.KindID, A.ServerID, A.TableID, A.UserCount, A.AndroidCount, A.Waste, A.Revenue, A.UserMedal, A.StartTime, A.ConcludeTime,
A.InsertTime, B.KindName, C.ServerName, sum(D .Score) AS Score, CASE A.KindID WHEN 108 THEN max(d .BackScore - Score)
ELSE d .BackScore END AS BackScore, D .BackInsureScore, E.gameid, E.accounts, E.nickname, E.lastlogonip, E.LastLogonType, E.userID
FROM RecordDrawInfo AS A LEFT JOIN
GameKindItem AS B ON A.KindID = B.KindID LEFT JOIN
GameRoomInfo AS C ON A.ServerID = C.ServerID JOIN
RecordDrawScore AS D ON A.DrawID = D .DrawID LEFT JOIN
AccountsInfo AS E ON D .UserID = E.userID
GROUP BY A.DrawID, A.KindID, A.ServerID, A.TableID, A.UserCount, A.AndroidCount, A.Waste, A.Revenue, A.UserMedal, A.StartTime, A.ConcludeTime,
A.InsertTime, B.KindName, C.ServerName, D .Score, D .BackInsureScore, E.gameid, d .backinsurescore, e.accounts, E.nickname, E.lastlogonip,
E.LastLogonType, E.userID, d .BackScore) AS tab
GROUP BY DrawID, KindID, ServerID, TableID, UserCount, AndroidCount, Waste, Revenue, UserMedal, StartTime, ConcludeTime, InsertTime, KindName, ServerName,
BackInsureScore, gameid, accounts, nickname, lastlogonip, LastLogonType, userID
HAVING sum(Score) != 0


这里其中,RecordDrawInfo 28W数据,RecordDrawScore 25W数据量,其他表只有不到3000的数据量。
现在这个SQL 查询需要10多秒, 我加了聚集索引,要15秒。
30W的数据量 不应该会出现这么久的查询。
希望大佬们给个解决方法
...全文
1309 34 打赏 收藏 举报
写回复
34 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
sywcf 2018-06-26
1.有些查询直接显示 就是不会太快,分页一定要要存储过程中做,而不是程序中做,不知你是在哪做的.
2. 8楼,9楼,已经给出了解决方案,楼主仔细看看啊,
  • 打赏
  • 举报
回复
peng2739956 2018-06-15
引用 30 楼 yenange 的回复:
[quote=引用 29 楼 foren_whb 的回复:] [quote=引用 28 楼 yenange 的回复:] [quote=引用 26 楼 foren_whb 的回复:] 但是!!!! 不能优化语句,不等于没有办法解决问题!!! 我的建议,就是使用索引视图,建立一张统计表 这样每次直接简单查询这张视图表就行了
索引视图要求相当严格, 他搞这么多表, 还有几次分组, 几乎不可能的了。[/quote] 索引视图可以只做里面的那层分组查询[/quote] 也困难, 你实际做一个多表的就知道了, 聚集唯一的索引都不容易[/quote] 真没辙了?
  • 打赏
  • 举报
回复
吉普赛的歌 2018-06-15
引用 29 楼 foren_whb 的回复:
[quote=引用 28 楼 yenange 的回复:] [quote=引用 26 楼 foren_whb 的回复:] 但是!!!! 不能优化语句,不等于没有办法解决问题!!! 我的建议,就是使用索引视图,建立一张统计表 这样每次直接简单查询这张视图表就行了
索引视图要求相当严格, 他搞这么多表, 还有几次分组, 几乎不可能的了。[/quote] 索引视图可以只做里面的那层分组查询[/quote] 也困难, 你实际做一个多表的就知道了, 聚集唯一的索引都不容易
  • 打赏
  • 举报
回复
丰云 2018-06-15
引用 28 楼 yenange 的回复:
[quote=引用 26 楼 foren_whb 的回复:] 但是!!!! 不能优化语句,不等于没有办法解决问题!!! 我的建议,就是使用索引视图,建立一张统计表 这样每次直接简单查询这张视图表就行了
索引视图要求相当严格, 他搞这么多表, 还有几次分组, 几乎不可能的了。[/quote] 索引视图可以只做里面的那层分组查询
  • 打赏
  • 举报
回复
吉普赛的歌 2018-06-15
引用 26 楼 foren_whb 的回复:
但是!!!! 不能优化语句,不等于没有办法解决问题!!! 我的建议,就是使用索引视图,建立一张统计表 这样每次直接简单查询这张视图表就行了
索引视图要求相当严格, 他搞这么多表, 还有几次分组, 几乎不可能的了。
  • 打赏
  • 举报
回复
丰云 2018-06-15
前面算了。。。。7百万关联3000,210亿了。。。。
  • 打赏
  • 举报
回复
丰云 2018-06-15
但是!!!! 不能优化语句,不等于没有办法解决问题!!! 我的建议,就是使用索引视图,建立一张统计表 这样每次直接简单查询这张视图表就行了
  • 打赏
  • 举报
回复
丰云 2018-06-15
别瞎忙活了,你这语句快不了 首先,28万关联25万就是七百万,再关联3000,就是2100万,再关联的表哪怕只有几百条,也有上亿 这么大的数据量的关联处理,能快吗? 其次,语句里有分组和统计函数,这样又导致索引失效, 然后,你的语句里还嵌套有分组统计。。。。 最后,你的语句里竟然没有过滤条件。。。。。 我的天呐。。。。。这是一个完全最大条件分组查询!!!!!!! 优化个毛线!!!!!
  • 打赏
  • 举报
回复
xiaoxiangqing 2018-06-15
有些字段看能不能建成复合索引
  • 打赏
  • 举报
回复
SRCS000 2018-06-15
引用 16 楼 shinger126 的回复:
[quote=引用 15 楼 SRCS000 的回复:] GROUP BY 这里容易导致索引不工作
没听说过GROUP BY会导致索引不工作的说法..[/quote] 尝试看看。。。你确定就一定没有?
  • 打赏
  • 举报
回复
丰云 2018-06-15
引用 31 楼 peng2739956 的回复:
[quote=引用 30 楼 yenange 的回复:] [quote=引用 29 楼 foren_whb 的回复:] [quote=引用 28 楼 yenange 的回复:] [quote=引用 26 楼 foren_whb 的回复:] 但是!!!! 不能优化语句,不等于没有办法解决问题!!! 我的建议,就是使用索引视图,建立一张统计表 这样每次直接简单查询这张视图表就行了
索引视图要求相当严格, 他搞这么多表, 还有几次分组, 几乎不可能的了。[/quote] 索引视图可以只做里面的那层分组查询[/quote] 也困难, 你实际做一个多表的就知道了, 聚集唯一的索引都不容易[/quote] 真没辙了?[/quote] 用触发器,但效果可能更差,如果这几张表改动频繁,那数据库会卡死。。。 实在不行就只能从业务看有没有办法优化了
  • 打赏
  • 举报
回复
吉普赛的歌 2018-06-14
引用 20 楼 peng2739956 的回复:
现在的问题是这个结果集出来是28W的数据量 但是我是做了分页功能的,1页也就10条,但是还是很慢。 现在的做法 我把分组和sum,max 这些一并去掉之后,能秒查。但是其实数据会出现一些异常的错误,虽然只是一小部分,但是还是会影响到。另外这本身是一个视图 我只是单独将这快提取出来了而已。
主表先分页, 再和其它表去关联过滤吧
  • 打赏
  • 举报
回复
peng2739956 2018-06-14
现在的问题是这个结果集出来是28W的数据量 但是我是做了分页功能的,1页也就10条,但是还是很慢。 现在的做法 我把分组和sum,max 这些一并去掉之后,能秒查。但是其实数据会出现一些异常的错误,虽然只是一小部分,但是还是会影响到。另外这本身是一个视图 我只是单独将这快提取出来了而已。
  • 打赏
  • 举报
回复
leo_lesley 2018-06-14

--先查看一下表页面碎片程度

dbcc showcontig(RecordDrawInfo)
dbcc showcontig(RecordDrawScore)
  • 打赏
  • 举报
回复
peng2739956 2018-06-14
引用 21 楼 yenange 的回复:
[quote=引用 20 楼 peng2739956 的回复:] 现在的问题是这个结果集出来是28W的数据量 但是我是做了分页功能的,1页也就10条,但是还是很慢。 现在的做法 我把分组和sum,max 这些一并去掉之后,能秒查。但是其实数据会出现一些异常的错误,虽然只是一小部分,但是还是会影响到。另外这本身是一个视图 我只是单独将这快提取出来了而已。
主表先分页, 再和其它表去关联过滤吧[/quote] 这个视图是这样的 A UNOIN ALL B UNOIN ALL C 也就是3个unoin。
  • 打赏
  • 举报
回复
吉普赛的歌 2018-06-13
其实跟你的结果集很有大的关系。 你最后的结果集有 30 万? 如果是 30 万, 你想想看, 一个表有 30 万, 而且还有很多的字段, 不作任何的连接过滤分组, 直接输出出来难道就很快? 直接 select * from tableName 输出大表快不了, 你又怎么能指望做了复杂的连接过滤分组的SQL快起来? 如果可以接受分页的话, 建议你分页; 如果不可以分页, 那就做成报表, 凌晨生成, 后面查结果表。
  • 打赏
  • 举报
回复
peng2739956 2018-06-13
这帖子不会凉了吧
  • 打赏
  • 举报
回复
peng2739956 2018-06-13
引用 5 楼 sinat_28984567 的回复:
group by 统计一遍sum可以做到吗?字段太多没看清。另外如果实在慢,可以把sum的值存一个临时字段
30W的数据量,百万级都不到 为何会这么慢。 我都郁闷坏了。
  • 打赏
  • 举报
回复
二月十六 2018-06-13
group by 统计一遍sum可以做到吗?字段太多没看清。另外如果实在慢,可以把sum的值存一个临时字段
  • 打赏
  • 举报
回复
peng2739956 2018-06-13
真实的SQL 其实是一个视图, 这个只是其中的一个,另外有UNION ALL 另外的3个查询,不过另外3个查询开销都不大,只有这个开销是最大的。 各位大版,帮忙啊 @二月十六 @中国风 @唐诗三百首 @OwenZeng_DBA @吉普赛的歌 @卖水果的net
  • 打赏
  • 举报
回复
加载更多回复(14)
发帖
疑难问题

2.1w+

社区成员

MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
加入社区
帖子事件
创建了帖子
2018-06-12 06:00
社区公告
暂无公告