什么是创建策略的索引？
是否可以在SQL Server的同一列上创建多个非群集索引？
在同一列上创建群集和非簇的方式怎么样？
非常抱歉，但是索引对我很困惑。
有什么方法可以找出SQL Server中估计的查询执行时间？
这些单词相当逻辑，您会非常了解它们迅速地。：）
在外行的术语中，寻求意味着要寻找记录的精确位置，这是SQL Server搜索列时的SQL Server所做的，而您的过滤器（Whewhere条件）足够精确。
扫描是指查询执行计划者估计更快地获取整个范围而不是单独寻求每个值的速度更大的行。
是的，您可以在同一字段上有多个索引，有时这可能是一个很好的主意。使用索引播放，并使用查询执行程序来确定发生的情况（SSMS中的快捷方式：CTRL M）。您甚至可以运行两个版本的同一查询版本，执行计划器将轻松显示每个版本的资源和时间，使优化变得非常容易。
，但是要对此进行一些扩展，请说您有一个地址表，并且有超过10亿的记录：
CREATE TABLE ADDRESS
(ADDRESS_ID INT -- CLUSTERED primary key ADRESS_PK_IDX
, PERSON_ID INT -- FOREIGN KEY, NONCLUSTERED INDEX ADDRESS_PERSON_IDX
, CITY VARCHAR(256)
, MARKED_FOR_CHECKUP BIT
, **+n^10 different other columns...**)
现在，如果您想找到第12345人的所有地址信息，则Person_ID上的索引是完美的。由于该表在同一行上有大量其他数据，因此创建一个非集群索引以覆盖所有其他列以及Person_ID将是效率低下且耗费空间的。在这种情况下，SQL Server将在Person_ID中执行索引搜索索引，然后使用该索引在address_id中的群集索引上进行键查找，然后从那里返回同一行上所有其他列中的所有数据。p>但是，说您想搜索城市中的所有人员，但是您不需要其他地址信息。这次，最有效的方法是在城市上创建一个索引，并使用涵盖Person_ID的选项。这样，单个索引搜索/扫描将返回所需的所有信息，而无需诉诸于同一行上的Person_ID数据的群集索引。
现在，假设这两个查询都是必需的，但由于记录了10亿个问题，但仍然相当沉重。但是，有一个特殊的查询需要非常快。该查询希望所有已被标记的地址上的人，并且必须居住在纽约（忽略任何检查的含义，这没关系）。现在，您可能需要在Marked_For_Checkup和City上创建第三个过滤的索引，其中包括covering person_id，并带有一个过滤器，说city ='new York''和marked_for_checkup =1。此索引会很快快，因为它只有覆盖查询均已封面查询这满足了这些确切条件，因此与其他索引相比，数据的一小部分要通过。
（在这里免责声明，请记住查询执行计划不愚蠢，它可以一起使用多个非集群索引来产生正确的结果，因此上面的示例可能不是可用的示例，因为很难想象什么时候您需要3个不同的索引来涵盖同一列，但我确定您明白了。）
索引类型，列，包括列，排序订单，过滤器等完全取决于情况。您将需要制作覆盖索引，以满足几种不同类型的查询，以及专门为单数，重要查询而创建的自定义索引。每个索引都会占用HDD上的空间，因此使无用的索引浪费浪费，并且每当数据模型更改时都需要额外的维护，并且将时间浪费在碎片整理和统计信息上更新操作...因此，您不想只在所有内容上拍打索引
实验，学习和锻炼哪种最适合您的需求。
我也不是索引专家，但这是我所知道的。
-
您只能每个表只有一个聚类索引。
-
您可以每张表的非聚类索引的一定限制。inoncluster-index-in-sql-server？forum = tracsactsql
-
索引应该只有不同的名称，但是最好不要在许多不同的索引上使用相同的列，因为您会遇到某些性能问题。
要记住的一个非常重要的点是，尽管索引使您的选择更快，但会影响您的插入/更新/删除速度，因为需要将信息添加到索引中，这意味着您在列上拥有的索引越多，得到很多更新，将大大降低更新的速度。
您可以在一个或多个非聚类索引中包含在聚类索引上使用的列。
这里还有一些阅读材料
http://www.sqlteam.com/article/sql-server-indexes-the-basicshttp://www.programmerinternview.com/index.php/database-sql/what-is-an-index/
编辑
要记住的另一点是，索引像桌子一样占用空间。您创建的索引越多，它使用的空间就越多，因此请尽量不要在索引中使用char/varchar（或nchar/nvarchar）。它使用了索引中的大量空间，并且在巨大的列中基本上没有任何好处。当您的索引开始变得比桌子更大时，这也意味着您必须重新制定索引策略。