数据库索引优化

2014-04-29 04:14:01 297 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

Cosmos DB 索引优化实战技巧 Azure Cosmos DB索引优化策略（150字摘要）本文针对Azure Cosmos DB提出核心优化方案：1）索引策略配置，通过包含/排除路径精准控制索引范围；2）复合索引优化多条件查询与排序；3）矢量索引分片提升向量搜索性能；4）数组字段采用属性提取或多键索引避免全扫描；5）动态吞吐量调整与分区键设计避免热分区。建议结合业务场景精简索引，定期监控RU消耗，删除冗余路径，并利用EXPLAIN分析查询计划。电商案例显示复合索引可提升订单查询效率30%+，矢量索引优化使推荐系统响应速度提升50%。阅读详情

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))

请高手指定。

...全文

Chapter 7 Linear Voltage Regulators 这一章我们介绍LDO. 阅读详情

kevin#1

疑难问题 22,298 成员 121,727 内容

+ 关注 + 加入社区

切换为时间正序

發糞塗牆 2014-04-30

打赏
举报

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

kevin#1 2014-04-30

打赏
举报

引用 6 楼 DBA_Huangzj 的回复:

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

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

Seven_Fox 2014-04-30

打赏
举报

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

kevin#1 2014-04-30

打赏
举报

引用 13 楼 DBA_Huangzj 的回复:

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

發糞塗牆 2014-04-30

打赏
举报

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

kevin#1 2014-04-30

打赏
举报

引用 11 楼 DBA_Huangzj 的回复:

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

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

發糞塗牆 2014-04-30

打赏
举报

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

kevin#1 2014-04-30

打赏
举报

引用 9 楼 DBA_Huangzj 的回复:

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

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

發糞塗牆 2014-04-29

打赏
举报

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

kevin#1 2014-04-29

打赏
举报

引用 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

發糞塗牆 2014-04-29

打赏
举报

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

發糞塗牆 2014-04-29

打赏
举报

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

kevin#1 2014-04-29

打赏
举报

引用 1 楼 DBA_Huangzj 的回复:

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

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

發糞塗牆 2014-04-29

打赏
举报

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

数据库索引优化

相关推荐