利用case when 减少表扫描次数

原文:利用case when 减少表扫描次数

数据库环境:SQL SERVER 2008R2

有网友希望有人帮他优化一下他的SQL,SQL语句如下:

WITH T AS (
SELECT B.O_Money MON,B.O_States STATES FROM M_Basket A JOIN M_OrderInfo B ON A.OrderID=B.ID WHERE A.GoodID=@GOODSID
),
B AS (
SELECT  (SELECT SUM(MON) FROM T)SumMoney,
(SELECT SUM(MON) FROM T WHERE STATES IN (2,3,4))ComfirmMoney,
(SELECT COUNT(*) FROM T WHERE STATES=2)AleadyDrive,
(SELECT COUNT(*) FROM T WHERE STATES=3)AleadyPay,
(SELECT COUNT(*) FROM T WHERE STATES=4)AleadyComfirm
)
INSERT @BIAO
SELECT * FROM B

看了一下语句,有可能出问题的地方,是with B 里面的内容,T表被访问了4次,

稍微转换一下思路,用case when来改写这段,就可以让T表只访问1次。

改写的SQL如下:

WITH    T AS ( SELECT   B.O_Money MON ,
                        B.O_States STATES
               FROM     M_Basket A
                        JOIN M_OrderInfo B ON A.OrderID = B.ID
               WHERE    A.GoodID = @GOODSID
             ),
        B AS ( SELECT   SUM(MON) AS SumMoney ,
                        SUM(CASE WHEN STATES IN ( 2, 3, 4 ) THEN MON
                            END) AS ComfirmMoney ,
                        COUNT(CASE WHEN STATES = 2 THEN 1
                              END) AS AleadyDrive ,
                        COUNT(CASE WHEN STATES = 3 THEN 1
                              END) AS AleadyPay ,
                        COUNT(CASE WHEN STATES = 4 THEN 1
                              END) AS AleadyComfirm
               FROM     T
             )
    INSERT  @BIAO
            SELECT  *
            FROM    B

(本文完)

时间: 2024-11-06 23:05:16

利用case when 减少表扫描次数的相关文章

查看表扫描次数,并对比索引对表查询的作用

1.什么是表扫描 当执行SQL 语句时,可通过""评估执行计划",查看语句的执行计划.尤其是语句设计查询,会出现"表扫描"部分: 表扫描是严重影响查询时间的因素! 2.验证 (1)新建数据表BasicMsg20161204,主键为自增列,但是将聚集索引建立在(RecvTime,AA,MsgTypecode)上: (2)新建数据表BasicMsg20161104,主键为自增列,且该列为聚集索引:在RecvTime上有非聚集索引: (3)新建数据表BasicM

表访问方式---->全表扫描(Full Table Scans, FTS)

全表扫描(Full Table Scans, FTS) 全表扫描是指Oracle在访问目标表里的数据时,会从该表所占用的第一个区(EXTENT)的第一个块(BLOCK)开始扫描,一直扫描到该表的高水位线(HWM,High Water Mark),Oracle会对这期间读到的所有数据施加目标SQL的where条件中指定的过滤条件,最后只返回那些满足过滤条件的数据. 不是说全表扫描不好,事实上Oracle在做全表扫描操作时会使用多块读,ORACLE采用一次读入多个数据块 (database bloc

Oracle 表的访问方式(1) ---全表扫描、通过ROWID访问表

1.Oracle访问表的方式 全表扫描.通过ROWID访问表.索引扫描 2.全表扫描(Full Table Scans, FTS) 为实现全表扫描,Oracle顺序地访问表中每条记录,并检查每一条记录是否满足WHERE语句的限制条件.ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描,而不是只读取一个数据块,这极大的减少了I/O总次数,提高了系统的吞吐量,所以利用多块读的方法可以十分高效地实现全表扫描.需要注意的是只有在全表扫描的情况下才能使用多块读操作.在这种

执行计划-数据访问方式(全表扫描与4种索引的方式)

执行计划 Oracle执行计划的相关概念: Rowid:系统给oracle数据的每行附加的一个伪列,包含数据表名称,数据库id,存储数据库id以及一个流水号等信息,rowid在行的生命周期内唯一. Recursive sql:为了执行用户语句,系统附加执行的额外操作语句,譬如对数据字典的维护等. Row source(行源):oracle执行步骤过程中,由上一个操作返回的符合条件的行的集合. Predicate(谓词):where后的限制条件. Driving table(驱动表):又称为连接的

SQL 数据优化索引建suo避免全表扫描

首先什么是全表扫描和索引扫描?全表扫描所有数据过一遍才能显示数据结果,索引扫描就是索引,只需要扫描一部分数据就可以得到结果.如果数据没建立索引. 无索引的情况下搜索数据的速度和占用内存就会比用索引的检索慢和高.下面是一个例子 1:无索引的情况 Product表,里面没有任何索引,如下图: 从上图中,我悲剧的看到了,物理读是9次,也就说明走了9次硬盘,你也可以想到,走硬盘的目的是为了拿数据,逻辑读有1636次,要注意的是这里 的”次“是“页”的意思,也就是在内存中走了1636个数据页,我用dbcc

避免全表扫描的sql优化

对查询进行优化,应尽量避免全表扫描,首先应考虑在where 及order by 涉及的列上建立索引:  .尝试下面的技巧以避免优化器错选了表扫描: ·   使用ANALYZE TABLE tbl_name为扫描的表更新关键字分布. ·   对扫描的表使用FORCE INDEX告知MySQL,相对于使用给定的索引表扫描将非常耗时.            SELECT * FROM t1, t2 FORCE INDEX (index_for_column)             WHERE t1.

用合适的索引避免不必要的全表扫描

Oracle数据库里大部分SQL优化的问题都可以增加或减少索引的方式来解决,但这绝不是全部.当目标SQL语句所要查询的只是目标表中的一部分数据时,通过创建合适的索引就能够避免在没有索引的情况下为查询这一小部分数据而不得不采用全表扫描的操作,这样就降低了目标SQL语句的资源消耗,同时也会缩短了执行时间. 创建一张测试表及创建一个普通的单键值B树索引: SQL> create table t1 as select * from dba_objects; Table created. SQL> cr

ORA-03113 SQL中select语句全表扫描带来的异常

今天在ERP系统的维护过程中,业务人员反馈了一个问题过来,是ERP系统生产单模块的预览打印报表出错,看到后我逐步做了以下的排查: 1.尝试其他单据是否存在相同问题 2.直接打开水晶报表,将参数代入看看是否是报表问题 排查之后逐渐发现,问题出在数据源身上,找到返回数据集的存储过程,进入测试窗口检查是否运行正常,结果发现运行即进入卡死状态,进程无法中断,只好强行退出PL/SQL,这时候我估计到问题出在SQL语句上,因此将SQL语句复制到新的窗口,代入参数,如下: SELECT WO_NBR,WO_L

【大数据课堂0008】会引起全表扫描的几种SQL 以及sql优化

查询语句的时候尽量避免全表扫描,使用全扫描,索引扫描!会引起全表扫描的几种SQL如下 1.模糊查询效率很低: 原因:like本身效率就比较低,应该尽量避免查询条件使用like:对于like ‘%...%’(全模糊)这样的条件,是无法使用索引的,全表扫描自然效率很低:另外,由于匹配算法的关系,模糊查询的字段长度越大,模糊查询效率越低. 解决办法:首先尽量避免模糊查询,如果因为业务需要一定要使用模糊查询,则至少保证不要使用全模糊查询,对于右模糊查询,即like ‘…%’,是会使用索引的:左模糊lik