数据库索引优化

[kevin#1]

sql 2008

1.每个表中一个经常用到的字段，为 时间、是否有效，时间维度为月，但是字段类型为时间类型，我们都是用'201401' 来进行匹配，(利用到数据库的自动转型)，是否这样会存在效率上面的问题?

2.在做数据查询、修改、时都会用到，我现在的索引有 一个为id的聚集索引，和根据时间、是否有效的复合索引，感觉有些时候还是比较慢，在表查询的时候where后面有时候还会跟随一些筛选条件，是否这些也要添加到索引中去呢？

3.如这条语句，差不多执行了2个小时，不筛选是200多w,筛选后为40多w，临时表中有60多w，belong = '20140101' and p.isavailable = 1
为索引标识，如何优化。

update x_src_bendijiazhangduanxinxiang_mx
    set isdudect = '是' 
   from x_src_bendijiazhangduanxinxiang_mx p
  where p.belong = '20140101' and p.isavailable = 1
    and p.kt_time_bak is not null
    and p.number in(
 select parent_number from #ywdm
  where convert(varchar(7),DATEADD(mm, DATEDIFF(mm,0,td_time), 0),120 ) > convert(varchar(7),DATEADD(mm, DATEDIFF(mm,0,dateadd(month,-6,p.kt_time_bak)), 0),120)
    and convert(datetime,td_time,120 ) < convert(datetime,p.kt_time_bak ,120))

请高手指定。

[發糞塗牆]

1.每个表中一个经常用到的字段，为 时间、是否有效，时间维度为月，但是字段类型为时间类型，我们都是用'201401' 来进行匹配，(利用到数据库的自动转型)，是否这样会存在效率上面的问题? 答：有影响 2.在做数据查询、修改、时都会用到，我现在的索引有 一个为id的聚集索引，和根据时间、是否有效的复合索引，感觉有些时候还是比较慢，在表查询的时候where后面有时候还会跟随一些筛选条件，是否这些也要添加到索引中去呢？ 答：是否有效这个列一般只有两个值，选择性不高，不建议加索引，可以对时间进行非聚集索引化 3.如这条语句，差不多执行了2个小时，不筛选是200多w,筛选后为40多w，临时表中有60多w，belong = '20140101' and p.isavailable = 1 答：上执行计划

[kevin#1]

引用 1 楼 DBA_Huangzj 的回复:

1.每个表中一个经常用到的字段，为 时间、是否有效，时间维度为月，但是字段类型为时间类型，我们都是用'201401' 来进行匹配，(利用到数据库的自动转型)，是否这样会存在效率上面的问题? 答：有影响 2.在做数据查询、修改、时都会用到，我现在的索引有 一个为id的聚集索引，和根据时间、是否有效的复合索引，感觉有些时候还是比较慢，在表查询的时候where后面有时候还会跟随一些筛选条件，是否这些也要添加到索引中去呢？ 答：是否有效这个列一般只有两个值，选择性不高，不建议加索引，可以对时间进行非聚集索引化 3.如这条语句，差不多执行了2个小时，不筛选是200多w,筛选后为40多w，临时表中有60多w，belong = '20140101' and p.isavailable = 1 答：上执行计划

现在我的时间是为 非聚集索引，但还是很慢。 第三点你说 “上执行计划”，是索引的维护计划吗？

[發糞塗牆]

不是，ctrl+m，然后运行你的语句，下方会有一个图

[發糞塗牆]

ctrl+m 然后执行：

BEGIN TRAN
UPDATE  x_src_bendijiazhangduanxinxiang_mx
SET     isdudect = '是'
FROM    x_src_bendijiazhangduanxinxiang_mx p
WHERE   p.belong = '20140101'
        AND p.isavailable = 1
        AND p.kt_time_bak IS NOT NULL
        AND p.number IN (
        SELECT  parent_number
        FROM    #ywdm
        WHERE   CONVERT(VARCHAR(7), DATEADD(mm, DATEDIFF(mm, 0, td_time), 0), 120) > CONVERT(VARCHAR(7), DATEADD(mm,
                                                              DATEDIFF(mm, 0,
                                                              DATEADD(month,
                                                              -6,
                                                              p.kt_time_bak)),
                                                              0), 120)
                AND CONVERT(DATETIME, td_time, 120) < CONVERT(DATETIME, p.kt_time_bak, 120) )
ROLLBACK

[kevin#1]

引用 4 楼 DBA_Huangzj 的回复:

ctrl+m
然后执行：

BEGIN TRAN
UPDATE  x_src_bendijiazhangduanxinxiang_mx
SET     isdudect = '是'
FROM    x_src_bendijiazhangduanxinxiang_mx p
WHERE   p.belong = '20140101'
        AND p.isavailable = 1
        AND p.kt_time_bak IS NOT NULL
        AND p.number IN (
        SELECT  parent_number
        FROM    #ywdm
        WHERE   CONVERT(VARCHAR(7), DATEADD(mm, DATEDIFF(mm, 0, td_time), 0), 120) > CONVERT(VARCHAR(7), DATEADD(mm,
                                                              DATEDIFF(mm, 0,
                                                              DATEADD(month,
                                                              -6,
                                                              p.kt_time_bak)),
                                                              0), 120)
                AND CONVERT(DATETIME, td_time, 120) < CONVERT(DATETIME, p.kt_time_bak, 120) )
ROLLBACK

[發糞塗牆]

右键那个绿色的字，选择缺少索引定义，会在新页帮你创建好索引，改一下索引名，执行到你的库，然后再次运行查询，生成执行计划看看

[kevin#1]

引用 9 楼 DBA_Huangzj 的回复:

从执行计划来看，基本上已经很不错了，你可以加上： set statistics io on ; 你的select语句 set statistics io off; 把你加了索引和未加索引的IO信息显示出来对比一下，如果逻辑读明显降低，那么证明你的索引还是比较有效的。

如果在insert 或者 update 这张建了索引的表的时候是不这个insert、update执行效率会变慢啊？是否要将索引删掉了？ 索引方面我可以制定对于的索引执行计划，来进行维护。

[發糞塗牆]

不一定，还要看你更改的“量”，大部分的insert、update、delete都带有where条件，这就导致这些操作会先进行“select”，把需要更改的数据找出来，再处理，如果select的过程慢，那么修改的过程就快不了哪里去了

[kevin#1]

引用 11 楼 DBA_Huangzj 的回复:

不一定，还要看你更改的“量”，大部分的insert、update、delete都带有where条件，这就导致这些操作会先进行“select”，把需要更改的数据找出来，再处理，如果select的过程慢，那么修改的过程就快不了哪里去了

因为数据源 都是直接 insert 进来，不会带where。

[發糞塗牆]

看量，即使你全表每列都一个索引，如果insert个几百行，性能不会很明显降低

[kevin#1]

引用 13 楼 DBA_Huangzj 的回复:

看量，即使你全表每列都一个索引，如果insert个几百行，性能不会很明显降低

[Seven_Fox]

索引维护，版主大大已经给出了建议，我个人建议，语句上面，可以换个思路。。。。

[kevin#1]

引用 6 楼 DBA_Huangzj 的回复:

右键那个绿色的字，选择缺少索引定义，会在新页帮你创建好索引，改一下索引名，执行到你的库，然后再次运行查询，生成执行计划看看

亲爱的版主，这个算正常吗？

[發糞塗牆]

从执行计划来看，基本上已经很不错了，你可以加上： set statistics io on ; 你的select语句 set statistics io off; 把你加了索引和未加索引的IO信息显示出来对比一下，如果逻辑读明显降低，那么证明你的索引还是比较有效的。