基数在复合索引中起作用吗？如果是这样，什么？
我正在运行一个连接两列的查询，它使用了我认为是最优索引的，所以它让我重新思考我如何设计索引......
假设我们有一张表格列出了美国境内的所有城市。我的第一个本能就是在（州 - ＆gt; 城市）上建立一个聚集索引，这样如果我们需要查询所有城市对于一个 State ，它可能会针对该索引。此外，对于指定城市和州的查询，这将是一个很好的索引（这里我们可以假设城市，州是唯一的对）。
我遇到了一个查询，该查询基本上是一个表格，其中列出了特殊城市。因此，这是城市表的子集。我在 Special.City 和 Special.State 上指定了联接，但令我惊讶的是它使用了主键索引（由SQL服务器自动创建） 城市表而不是我制作的聚集索引。怎么样？
我也听说好的指数有很高的基数......
所以我想知道是否应该创建聚集索引（或另一个单独的索引）（ City - ＆gt; State ）（注意顺序上的差异）因为（我们假设）只是城市具有较高的基数，并且比第一系列桶中的 State 更具辨别力。
根据我的经验法则，始终在父子关系中创建父级＆gt;子级的聚簇索引（如城市和州），以使针对特定子级的查询和获取给定父级的所有子级的查询受益。我需要在这里重新思考一下吗？
非正式测试表明（城市 - > 州）的指数比PK指数略低。
答案 0 :(得分：1)
一些想法：
当您加入“特殊城市”时，您是否要求“城市”中的所有栏目或城市和州？也就是说，它涉及的内容
“特殊城市”的索引或PK订单是什么？
你有没有在任何地方过滤？
列的基数可以起到一定的作用：请参阅Craig Freedman's blog entry了解残差查找。并another one。
它在BOL中提到（虽然找不到）它应该是最具选择性的
但是，在使用多层表和复合键的情况下，这会分崩离析。例如：
儿子的PK涵盖了两个父表的FK需求。
如果您反转“爸爸”和“儿子”的顺序，因为DadID和SonID应该是选择性的GrandDadID，那么您突然需要更多的索引来覆盖查询和FK DRI。
所以：列基数起了作用，但它只是一个因素而且，呃，“它取决于”......
答案 1 :(得分：0)
您正在处理的索引类型（与身份代理键上的munchkin PK相反）可能是一堆蠕虫。人们可以写几个小时的主题，并不一定会说任何可以帮助你的情况。阅读有关索引和进行大量实验的文章可能是您最好的选择。
没什么帮助，唉。如果我能想到任何简洁的普遍真理，我可能会在稍后更新。