索引是在查询时,SQL根据查询语句进行判断使用那些索引所以不知道你要做那些处理,就无法分析索引的利用率,也无法分析索引的合理性
一般的索引建立规则是在经常用做条件/排序的字段上建立索引
如果某几个字段经常被用在同一个条件语句中,则一般在这些字段上建立复合索引,否则应该单独为那些字段建立索引
不用(或很少用)于条件或排序的字段上不应该建立索引,因为数据变化时,SQL要维护索引,所以更多的索引一方面会影响数据处理效率,另一方面,过多的索引在SQL选择SQL语句的执行方案时,会导致SQL做更多的尝试来寻找合适的执行方案,导致查询效率的下降
一般的索引建立规则是在经常用做条件/排序的字段上建立索引
如果某几个字段经常被用在同一个条件语句中,则一般在这些字段上建立复合索引,否则应该单独为那些字段建立索引
不用(或很少用)于条件或排序的字段上不应该建立索引,因为数据变化时,SQL要维护索引,所以更多的索引一方面会影响数据处理效率,另一方面,过多的索引在SQL选择SQL语句的执行方案时,会导致SQL做更多的尝试来寻找合适的执行方案,导致查询效率的下降
你可以结合上面的理论及查询分析器中的分析方法去分析你的索引创建是否合理
分析所建议的更改将会产生的影响，包括索引的使用，查询在表之间的分布，以及查询在工作负荷中的性能。
推荐为执行一个小型的问题查询集而对数据库进行优化的方法。
允许通过指定磁盘空间约束等高级选项对推荐进行自定义。
建议由 SQL 语句构成，执行这些语句可以创建更有效的新索引，如果需要，还可以除去无效的现有索引。建议在支持索引视图的平台上使用索引视图。索引优化向导提出建议后，该建议可以： 立即执行。
安排在以后通过创建执行 SQL 脚本的 SQL Server 作业执行。
保存到 SQL 脚本中，用户在将来某个时候或在另一个服务器上手工执行。
注意事项
对于下列项目，索引优化向导不推荐索引： 当前选定的数据库中不存在的跨数据库查询所引用的表。
系统表。
PRIMARY KEY 约束和唯一索引。
其它索引优化向导注意事项包括： 索引优化向导在一个工作负荷中最多可以包含 32,767 个可优化查询。负荷中超出此数目的查询将不被考虑。此外，带有被引用的标识符的查询将不予优化。
索引优化向导通过数据采样搜集统计信息。因此，如果连续在同一个工作负荷上执行该向导，则每次推荐的索引可能各不相同，执行推荐索引后的改进效果也可能各不相同。
索引优化向导不能用于在 SQL Server 6.5 版或更早版本的数据库上选择或创建索引和统计信息。
当把 SQL 脚本保存到可用空间不足的磁盘上时，索引优化向导并不给出错误。
在分析过程中，索引优化向导会消耗相当多的 CPU 及内存资源。最好在生产服务器的测试版上执行优化，而不要在生产服务器上执行。此外，最好在另一台计算机上而非运行 SQL Server 实例的计算机上运行该向导。
在下列情况下，索引优化向导可能不会提供索引建议： 被采样的表中数据不足。
建议的索引对现有索引的查询性能预计带来的改进不够充分。
工作负荷中的查询在唤醒调用索引优化向导的用户的安全上下文中进行分析。该用户必须是固定服务器角色 sysadmin 的成员。为减少索引优化向导的执行时间： 确保在"选择服务器和数据库"对话框中未选择"进行彻底分析"。进行彻底分析将会使索引优化向导对查询进行详尽的分析，导致执行时间延长。但选择此选项可以使所优化的工作负荷的性能得到更大的全面提高。
只对数据库中表的子集进行优化。
减小工作负荷文件的尺寸。
如果选定了"保留所有现有索引"选项，则索引优化向导不建议除去任何索引，而是在适当的时候只建议新索引。如果清除此选项，则工作负荷的性能会全面提高。此外，索引优化向导也不会推荐除去对 PRIMARY KEY 约束的索引或 UNIQUE 索引。但可能会除去或替换不是唯一或不是当前在 PRIMARY KEY 约束上创建的索引。索引优化向导在最终建议内包括所有索引提示或查询提示，即使索引对于表并非是最佳的。可能会提议和建议查询中引用的其它表上的索引；然而，所有指定为提示的索引始终是最终建议的一部分。但提示会妨碍索引优化向导选择更好的执行计划。因此在分析工作负荷之前应考虑从查询中删除所有索引提示。在 SQL 查询分析器中使用索引优化向导
SQL 查询分析器中的索引分析使得可以对单个查询或成批查询进行分析，并为用于支持给定查询或成批查询的优化索引集生成建议。只有 sysadmin 固定服务器角色成员才可以使用 SQL 查询分析器进行索引分析。若要推迟生成索引优化向导所建议的索引，可使用 SQL 查询分析器保存建议的 SQL 脚本。将 SQL 脚本保存到文件中，可以使索引分析推荐的 Transact-SQL 语句在执行前得到检查，从而可以在执行前对 SQL 脚本进行编辑（例如，可以更改所生成的索引的名称）。