注:
本文译自https://www.sqlskills.com/blogs/paul/missing-index-dmvs-bug-that-could-cost-your-sanity/
原文作者是在SQL Server 2008 SP1下面说的这个问题,本人在SQL Server 2014 SP2下测试仍有有这个问,因此记录了下来
本人原本打算利用missing index的DMV中的信息做创建索引使用,之前就一直怀疑SSMS中提示的索引是否有效,
通过这篇文章,让我们重新认识missing index的DMV中的信息。
本文出处:http://www.cnblogs.com/wy123/p/6635735.html
译文如下:
使用missing index DMVs时需要非常小心的原因(之一)
missing index DMVs有一个bug,最终可能会让你把你的头靠在一堵砖墙,质疑你的理智,我知道我曾经做过这样的事
这个bug就是:缺失索引代码可能会一次又一次建议创建一个已经存在的非聚集索引,也有可能建议一个没有对查询有实际帮助的索引
是的,我对这种现象也感到吃惊-就像是查询优化器里missing index code一样,
尽管如此,它依旧会继续建议你创建一个已经存在的索引,非常讨厌
这是一个鲜为人知的bug,已经在SQL11中修复(Connect item #416197),
但是之前的版本并没有修复(译者注:在SQLServer2014 SP2版本中测试,这个问题仍然存在)
本周末,我在SQL Server2008 SP1中遇到过这个问题,因此我想用博文记录下来,因此你们不用花时间去尝试解决这是怎么回事
这里来重现这种现象:
CREATE TABLE t1 ( c1 INT IDENTITY, c2 AS c1 * 2, c3 AS c1 + c1, c4 CHAR (3000) DEFAULT 'a' ); GO CREATE UNIQUE CLUSTERED INDEX t1_clus ON t1 (c1); GO SET NOCOUNT ON; GO INSERT INTO t1 DEFAULT VALUES; GO 100000
这里创建了一张带有突出一行的表(每行中有一个字段很长),由于每一行都相当的大以至于表扫描的代价很大
现在来运行这个查询
这里我按照它的提示创建一个索引,这一切都很酷
CREATE NONCLUSTERED INDEX [_missing_c2_c3] ON [dbo].[t1] ([c2],[c3]); GO
现在,如果我想做一些更加复杂的事情,在表上开启一个游标(不要说关于不使用游标的问题--他们在应用程序中到处都是,这对工程师来说是个很简单的例子)
DECLARE testcursor CURSOR FOR SELECT c1 FROM t1 WHERE c2 BETWEEN 10 AND 1000 AND c3 > 1000; DECLARE @var BIGINT; OPEN testcursor; FETCH NEXT FROM testcursor INTO @var; WHILE (@@fetch_status <> -1) BEGIN -- empty body FETCH NEXT FROM testcursor INTO @var; END CLOSE testcursor; DEALLOCATE testcursor;
如果显示预估的执行计划,参考下图,
这个索引提示恰好是之前已经创建过的了(即使这里要求c1列被包含进来)
提示创建的这个索引实际上已经存在了,由于c1是聚集索引列,他已经被自动地包含在非聚集索引中了
(译者注:懵逼了一下,突然想起来非聚集索引将聚集索引键作为其行指针,这样c1自然在已经建立的索引中了)
尽管如此,为了证明我没有做什么狡猾的事,我继续按照他的提示来它想要的索引
CREATE NONCLUSTERED INDEX [_missing_c2_c3_inc_c1] ON [dbo].[t1] ([c2],[c3]) INCLUDE ([c1]); GO
然而一切如故,你无法停止提示提示缺少索引的代码停下来
*Key Lookup* 在上面的执行计划中
但是(优化器)提示的缺少索引的代码认为这个索引是有用的并且建议创建它,
实际上这个索引并没有任何帮助,它确实已经存在了。
如果你使用一个查询统计missing index DMV,你的系统里有很多普通的查询将会被这个bug击中,
同时也会发现missing index DMV统计结果是被损坏了的。
因此这里要小心了。
译者注:
多次运行上面这个游标SQL之后,根据missing index DMV查询的结果,果然有这个坑爹的missing index