Os和其他性能监控工具不一样，无法通过配置去管理，它是自动运作的。在使用这些信息时，有下面的注意事项：
1、队列的大小，这一点很多人都忽略了，SQLServer只会收集最多500个缺失索引组，一旦到达这个限制，就会停止收集新的缺失索引信息。缺失索引组其实是一系列的缺失索引信息，后面会提到。对于这个限制，只能通过周期性监控并尽快处理，让优化器能够报告更多的缺失索引信息。
2、分析深度，SQLServer会报告缺失索引的信息，并给出它的建议，但是要注意分析的深度，这些建议仅针对当前的执行计划，有时候根据建议添加索引后，会出现新的缺失索引信息，而且给出的建议中，可能不会考虑列的顺序，所以当查看这些信息时，需要做足够的测试。
3、准确度，当查询使用不等于这种限定词，比如在where中使用了A<>B这样的写法，缺失索引给出的信息准确度就没有使用等于这种限定词高。
4、索引类型，缺失索引对聚集索引、XML、空间或者列存储索引不可用。
除此之外，当表的元数据改变时，缺失索引的信息也会消失，比如增加新列这些操作。这部分的DMOs包含：sys.dm_db_missing_index_details、sys.dm_db_missing_index_columns、sys.dm_db_missing_index_group_stats、sys.dm_db_missing_index_groups
但是需要说明的是：别看到SQLServer提示了就加，这是导致索引过多的主要原因，要分析、要测试！
?
分析聚集索引：
现在换一个环境，用AdventureWorks2008R2作为演示。使用前文创建的dbo.person表，并删除除主键外的所有索引。
?
现在在表上没有任何非聚集索引。那么我们还是使用前文中的查询语句：
?
select Title,FirstName,MiddleName,LastName
from dbo.Person
where FirstName like 'o%'
?
?
为了让SQL Server能收集足够的信息，我们重复执行这个语句10次。然后用前面检查索引被使用情况的语句检查这个聚集索引：
?
?
点开第一个执行计划可以看到：
?
结合语句可知，它仅仅使用了四列，由于FirstName不是主键且上面没索引，所以走的是聚集索引扫描。如果聚集索引建在FirstName，可以看到走的是聚集索引查找，因为鼠标移到箭头上可以看到实际上返回了164行，而全表有19972行数据，这种比例是可以进行查找操作的。不过主键毕竟需要唯一非NULL，所以这里就不演示了。
通过分析，我们初步判断可以通过对这四列进行索引化，并且以FirstName为索引首列来提高性能，但是为了验证想法，我们用上面给出的缺少索引的语句来验证，也可以用DTA来检验，记住，DTA有很多限制和不足的地方，不要盲目相信：
?
很多时候缺少索引的DMOs记录的恰恰就是DTA的提示，但是这些DMOs更加完善，由于这里是演示环境，系统并没有收集足够的信息，所以DMOs没有显示。
这种分析确实比较累人，建议结合缺少索引的提示和DTA来分析。切记要分析和测试。
?
总结：
本系列文章通过一些工具，粗暴但不失有效地检测和分析系统常见的索引问题。另外，本方法确实不是什么精密的、能覆盖所有可能的方法，如果需要精密严谨地分析，需要借助很多工具、长时间收集和反复监控。但是作为实践所得，本人觉得这两篇文章还是有很重要的用处。
处理过索引相关问题之后，有这么一个深刻体会：建一个索引很容易，也很快。说不好听，可以说完全不需要负责任。但是证明一个索引可以删除、可以合并，其实你需要花费大量的精力和时间，并且毫不夸张地说，你需要勇气。像本人管理的系统中，有500多个索引，抛开接近200个主键（聚集索引），如果要每个都检查，没有个把月专门做这事情是不现实的。