一段sql的优化

优化前代码

select *
,ROW_NUMBER() OVER(order by WrongCount desc) as rowId
from(select Quba_IDint,Quba_Number
,
           (select top 1 Sqre_AddDateTime
             from tbStudentStudyQuestionRecords where Sqre_QubaId=Quba_IDint and Sqre_StudentId=200
             and sqre_AnswerJudge=‘wrong‘ order by Sqre_AddDateTime desc) as Sqre_AddDateTime,
           (select top 1 Sqre_StudyFromType
             from tbStudentStudyQuestionRecords where Sqre_QubaId=Quba_IDint and Sqre_StudentId=200
             and sqre_AnswerJudge=‘wrong‘ order by Sqre_AddDateTime desc) as Sqre_StudyFromType,
				COUNT(Quba_IDint) as WrongCount
				,COUNT(distinct Expo_KnowPointIDint) as KnpoCount
           ,
           (select top 1 Sqre_MainId
             from tbStudentStudyQuestionRecords where Sqre_QubaId=Quba_IDint and Sqre_StudentId=200 and sqre_AnswerJudge=‘wrong‘
              order by Sqre_AddDateTime desc) as Sqre_MainId
     from tbStudentStudyQuestionRecords
     left join tbQuestionBank on Sqre_QubaId=Quba_IDint
     left join tbQuestionType on QuTy_Id=Quba_Type
     left join tbExamKnowPoint on Expo_ExamIDint=Quba_IDint
     where Sqre_StudentId=200 and Quba_SubjectId=15 and Sqre_AnswerJudge=‘wrong‘ and QuTy_Name<>‘综合题‘
     group by Quba_IDint,Quba_Number)as t order by quba_idint

  

优化后代码

select t.*,Sqre_AddDateTime,Sqre_StudyFromType,Sqre_MainId,Sqre_QubaId,
	ROW_NUMBER() OVER(order by WrongCount desc) as rowId
      from (select Quba_IDint,Quba_Number,QuTy_Name,
					COUNT(Quba_IDint) as WrongCount
				,COUNT(distinct Expo_KnowPointIDint) as KnpoCount,max(Sqre_Id) as lastId
             from tbStudentStudyQuestionRecords
             left join tbQuestionBank on Sqre_QubaId=Quba_IDint
			 left join tbQuestionType on QuTy_Id=Quba_Type
			 left join tbExamKnowPoint on Expo_ExamIDint=Quba_IDint
             where Sqre_StudentId=200 and sqre_AnswerJudge=‘wrong‘ and Quba_SubjectId=15 and QuTy_Name<>‘综合题‘
             group by Quba_IDint,Quba_Number,QuTy_Name) as t
             left join tbStudentStudyQuestionRecords on t.lastId=Sqre_Id

 

而已看到优化后执行时间不用1秒 

优化思路,第一个sql因为有三个其实查的都是同一条语句,但是因为子查询不能查三列,之前就是这样写的。

所以想着用左连接来优化,先取出一部分,再取出一部分然后连接。

时间: 2024-10-21 02:19:51

一段sql的优化的相关文章

Oracle SQL性能优化

转载自:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection ta

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

转:sql语句优化

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL通用优化方案(where优化、索引优化、分页优化、事务优化、临时表优化)

SQL通用优化方案:1. 使用参数化查询:防止SQL注入,预编译SQL命令提高效率2. 去掉不必要的查询和搜索字段:其实在项目的实际应用中,很多查询条件是可有可无的,能从源头上避免的多余功能尽量砍掉,这是最简单粗暴的解决方案.3. 选择最有效率的表名顺序: 数据库的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后,如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后.

&lt;转&gt;Oracle SQL性能优化

原文链接:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection t

撸一段 SQL ? 还是撸一段代码?

记得刚入公司带我的研发哥们能写一手漂亮的 SQL,搜索准确.执行快.效率高. 配合Web项目中的查询展示数据的需求,基本是分分钟完成任务. 那段时间基本是仰视的态度,每天都去讨教一点手写 SQL 的要点,翻看一些 SQL 优化调整的技巧. 随着积累和实践,SQL 水平提高的很快,同时也写了很多,有兴趣的可以看看:http://www.cnblogs.com/ 随后经历了几个项目的打磨,不断去调整公司的框架,发现项目中大段 SQL 出现的概率越来越小. 我不得不停下脚步,开始反思和总结出现这种现象

Oracle SQL语句优化34条

非常好用的SQL语句优化34条 1)选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基 础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. (2) WHERE子句中的连接顺序.: ORACL

[转]sql语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜.  连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行