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的数据量 不应该会出现这么久的查询。
希望大佬们给个解决方法
...全文
1378 34 打赏 收藏 转发到动态 举报
写回复
用AI写文章
34 条回复
切换为时间正序
请发表友善的回复…
发表回复
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）
Effective MySQL之SQL语句最优化
《Effective MySQL之SQL语句最优化》是由MySQL专家Ronald Bradford撰著，书 中提供了很多可以用于改进数据库和应用程序性能的最佳实践技巧，并对这些技巧 做了详细的解释。本书希望能够通过一步步详细介绍SQL优化的方法，帮助读者分 析和调优有问题的SQL语句。 主要内容 ●　找出收集和诊断问题必备的分析命令 ●　创建MySQL索引来改进查询性能 ●　掌握MySQL的查询执行计划 ●　找出影响查询执行和性能的关键配置变量 ●　用SQL语句优化的生命周期来识别、确 认、分析然后优化SQL语句，并检查优 化的结果 ●　学习使用不为常人所知的一些性能技巧 来改进索引效率并简化SQL语句
SQL语句常用优化技巧
SQL语句常用优化技巧
sql server 数据分析优化实战（一）——SQL语句优化
前言 在我们进行数据分析的时候，首要的目标是根据业务逻辑，通过编写SQL代码得到我们想要的结果，这是毋庸置疑的。一般情况下，由于我们分析的数据量比较少，体会不出SQL语句各种写法的性能优劣，对SQL代码的优化往往没那么重要。但是随着数据库中数据的增加，尤其是当一个系统需要对海量的数据进行持续性的分析时，SQL的运行效率就成为系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍甚至更多，可见对于数据分析，不是简
如何对 SQL 语句进行优化
当我们在设计一个项目时，开发阶段的业务数据量相对较少，一些 SQL 语句的执行效率对程序运行效率的影响不太明显，所以对于开发或运维人员来说不会注重对 SQL 语句的优化。但是，随着时间的积累，业务数据量会越来越多，SQL 的执行效率对程序的运行效率的影响逐渐增大，此时对SQL的优化就很有必要。 本篇章主要从以下几个方面对 SQL 语句的优化进行介绍： 插入数据优化 主键优化 order by 优化 group by 优化 limit 优化 count 优化 update 优化
提高sql语句查询效率
提高sql语句查询效率十分重要。以下是结合网上流传比较广泛的几个查询语句优化方法： 首先，数据量大的时候，应尽量避免全表扫描，应考虑在 where及 order by 涉及的列上建立索引，建索引可以大大加快数据的检索速度。但是，有些情况索引是不会起效的：1、应尽量避免在 where子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。2、应尽量避免在 ...
疑难问题

22,206

社区成员

121,729

社区内容

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章