令我有一个表像这样：SQL Server聚集索引 - 索引问题
keyA keyB data
科亚和KEYB在一起是独一无二的，是我的表的主键，构成了一个聚集索引。
keyB有5个可能的值，但keyA的可能值的数量不受限制。 keyB通常递增。
例如，下面的数据可以通过2种方式，这取决于键列排在第一位下令：
keyA keyB data
A 1 X
B 1 X
A 3 X
B 3 X
A 5 X
B 5 X
A 7 X
B 7 X
或
keyA keyB data
A 1 X
A 3 X
A 5 X
A 7 X
B 1 X
B 3 X
B 5 X
B 7 X
我需要告诉聚集索引，其中关键字列的可能值较少，因此它可以首先按该值排序数据？或者，首先排序的表现无关紧要？
你应该为了你的复合聚集索引最有选择性的列第一。这意味着与总行数相比，具有最明显值的列。
“B *树索引提高是从表中选择行的一小部分查询的性能。” http://www.akadia.com/services/ora_index_selectivity.html？
本文适用于Oracle，但仍然相关。另外，如果您有一个持续运行并返回少量字段的查询，则可以考虑创建一个包含所有字段的组合索引 - 它不必访问基本表，而是将索引中的数据。在确保组合索引提的第一列
ligget78的评论重要的是要记住。
您可以做的最好的事情是尝试两种解决方案并测量执行时间。
根据我的经验，索引调整只是精确的科学。
也许有KEYB科亚之前在索引列的顺序将是更好
我相信，SQL Server的下单吧正是你告诉它的方式。它假定你最清楚如何访问你的索引。
在任何情况下，我都会说这是一个好主意，在可能的情况下可以指定您想要的内容，而不是希望数据库能够找到它。
您也可以尝试两种方式，运行一系列具有代表性的查询，然后比较生成的执行计划以确定哪个最适合您。
给了这个upvote，但只是想指出，虽然这是很好的指定你想在这种情况下，通常你应该让服务器找出什么是最好的。例如，在查询中使用索引提示通常是一个坏主意，因为最好的计划可能会随着数据的变化而变化。 – 2008-12-05 15:31:38
如果你用（keyA，keyB）创建一个索引（不管是否聚类），那么这就是如何排序数值的。第一个keyA，然后是keyB（这是你问题中的第二个例子）。如果你想换个角度，你需要指定（keyB，keyA）。
它可能在性能方面很重要，当然取决于您的查询。例如，如果你有（keyA，keyB）索引，并且查询看起来像WHERE keyB = ...（没有提到keyA），那么索引不能被使用。
按照您通常希望在报告和查询中排序的顺序指定列。
虽然我会对创建多列聚集索引保持警惕。取决于它的宽度，可能会对您创建的任何其他索引的大小产生巨大影响，因为所有非聚簇索引都包含聚簇索引值。而且，如果值经常变化，则行必须重新排序，并且我的经验是，非代理键往往更频繁地变化。因此，如果您有可能更改的值，则将其创建为群集非聚集索引可能会耗费更多的服务器资源时间。我不是说你不应该这样做，因为我不知道你的列实际包含的是什么类型的数据（尽管我怀疑它们比A1，a2等更复杂）;我说你需要考虑这样做的后果。在做这件事之前，彻底阅读BOL有关集群副非索引索引可能是一个好主意。
正如其他人所说，顺序是根据你如何在索引创建脚本（或PK约束）指定。关于聚集索引的一点是，有很多事情需要记住。
您可能会通过使用比PK其他的东西你的聚集索引更好的整体性能。例如，如果您正在编写财务系统并且报告几乎总是基于活动的日期和时间（过去一年的所有活动等），那么该日期列上的聚集索引可能会更好。正如HLGEM所说，排序也会受到您选择聚集索引的影响。
聚集索引也可以影响比其他指标更插件。如果你有大量的插入，而你的聚集索引就像是一个IDENTITY列，那么这个特定部分的磁盘可能会出现争用问题，因为所有的新行都被插入到同一个地方。
对于小查找表我一直只是把对PK聚集索引。对于高影响力表格，尽管在选择最佳表格之前花时间思考（并测试）各种可能的聚集索引是一个好主意。
记住，聚集索引是在该表被存储在磁盘上的物理顺序。
所以，如果您的聚集索引的定义是可乐，COLB查询会更快，当以同样的顺序为您的聚集索引。如果SQL必须订购B，那么它需要执行后期排序以实现正确的订单。
我的建议是在B，A添加第二非聚簇索引。还取决于您的数据列的大小INCLUDE（读取包含列），以防止需要键查找。当然，假设这张表格没有大量插入，因为您总是必须平衡查询速度和写入速度。
实际上，你的聚集索引应表示其中数据是最有可能被访问，以及保持插入\ IO更新成本的微妙平衡的顺序。如果您的聚集索引是不断插入到页面中间的，您可能会遭受性能损失。
像其他人说，不知道该表的长度，列大小等，没有正确的答案。用大量的测试进行试验和错误是你最好的选择。
万一这不是很明显的：你指数的排序顺序不承诺很多有关结果的排序顺序在查询。
在查询中，你还必须加一个
ORDER BY KeyA, KeyB
或
ORDER BY KeyB, KeyA
优化程序可能会很高兴地发现需要的和节省一些时间在指数已经实际订购的数据，但是每个应该以特定顺序传递数据的查询在其末尾必须具有ORDER BY子句。如果没有命令，SQL Server不会对记录集的顺序做出任何承诺，甚至不会以从查询到查询的相同顺序返回。
是的，你应该建议，通常查询引擎试图找出最佳执行计划和索引来利用，但有时最好是强制查询引擎使用特定索引。规划索引时以及在查询中使用索引时还有一些其他考虑因素。例如，索引中的列排序，where子句中的列排序。您可以参考以下链接了解：
http://ashishkhandelwal.arkutil.com/sql-server/quick-and-short-database-indexes/
我相信这将帮助您规划索引。
它实际上是基于具体的科学思想。了解一下b-tree索引如何工作会让你知道更多的信息，并且需要更少的猜测工作。 – Sam 2008-12-05 16:02:19
诚实的+1。除非您确切知道SQL Server如何在内部工作，否则无法确定实际情况如何。 理论虽然很棒。没有，真的;） – 2008-12-06 14:41:39