>在我们删除索引之前,我们需要确保它是否强制执行
唯一性约束,因为查询优化器可能需要此索引
存在.
>每当创建索引时,与该索引相关的统计信息都是
也在sql Server中创建.查询可能没有使用索引但是
它可能正在使用其统计数据.所以我们可能遇到一种情况,
删除索引后,特定的查询性能确实如此
坏. sql Server不保留统计信息的使用情况统计信息.
虽然我们已启用“自动创建统计”功能
数据库,我不知道必须满足哪些参数
在查询优化器创建缺失之前的内部
统计.
关于#1,在我看来,sql Server实际上会在索引上进行搜索以确定插入/更新完成之前的唯一性,因此,索引不会显示为未使用.
关于#2,这真的有可能吗？
顺便说一句,当我说没有使用索引时,我的意思是没有搜索,也没有扫描.
@R_404_323@
Regarding #1,it seems to me that sql Server would actually do a seek on the index to determine uniqueness before an insert / update is done,and therefore,the index wouldn’t show as being not used.
优化器可以使用唯一性保证来决定可以使用哪些逻辑转换或物理操作来获得正确的结果.优化程序依赖唯一性保证(例如,转换聚合或选择一对多合并连接)这一事实不会反映在索引使用情况统计中,除非在最终执行计划中也物理访问索引.因此,应该非常小心地删除(或禁用)任何唯一索引或约束.
Regarding #2,is this really possible?
是的,优化器可以使用与索引关联的统计信息,而最终执行计划不包含使用该索引的任何访问.加载“有趣”统计数据,计算基数估计值和生成完成执行计划的过程是完全独立的活动.
删除索引也会删除关联的索引统计信息,这可能会在下次重新编译语句时影响计划质量.索引统计可以用在最终计划所依赖的基数估计计算中,即使索引实际上不存在于最终计划中也是如此.
你的DBA知道他/她的东西.
这些都不应被视为意味着永远不应删除明显未使用的索引.我只是说你的DBA的问题是有效的,你应该通过适当的测试和恢复计划相应地计划变更.根据我的经验,#1点比#2更容易出问题,但我无法知道这是否适用于您的情况.
