我们有一个非常大的数据库，并且一直在使用我们想要远离的分片。每当表变得非常大时，分片就会起作用，我们启动一个与前一个表具有相同模式的新表，并在另一个表中保留一个数字，以帮助我们找到数据所在的表。这是一个麻烦的手动过程，意味着我们将数据分布在N个不同的表中，所有表都具有相同的模式。
我们正在尝试的想法是通过使用索引来消除对分片的这种需求。我们的数据查询查询不使用唯一键，并返回许多跨列具有相同值的记录。
以下说明了我们对特定表的许多查找选择，带*的字段表示该字段可能在也可能不在select中。
where子句：scheduled_test，* script，* label，* error_message
group / order：messenger_id，timeslice，script，label，error_message，step_sequence，* adapter_type
我的想法是我不想创建一个包含所有这11个字段的索引。我选择了其中3个似乎更常用的东西，包括总是在where子句中的那个。我曾经读过，建议不要使用太多字段的索引太宽。我还听说优化器将首先使用索引字段，并且即使MSDN声明唯一索引是最大的优势，但使用非唯一索引并不罕见。这不是我们的数据设计方式。我意识到SQL会在索引中添加一些内容以使其独一无二，但这似乎并不重要。
当我在sql server management studio中查看类似于我们可能运行的查询的执行计划时，它会说“聚集索引寻求成本100％”，但它正在使用我创建的聚簇索引，所以我我希望这比默认的聚簇索引更好，它只是生成的主键（以前是如何定义表的）。我希望我在这里拥有的东西与我们的分片方法一样好或更好，并且不需要分片。
我们一次将大量数据插入到表中，但是这些行在许多列中都具有相同的数据值，我认为它们甚至会在最后插入。这些插入不与旧数据共享值，如果索引只有3列，那么这些插入对插入来说不是很大。
我说的话似乎合理，或者我应该考虑或考虑什么？非常感谢，我不熟悉这些类型的索引问题，但一直在寻找各种网站和实验。
答案 0 :(得分：3)
通常，聚簇索引越窄越好，因为聚簇索引的聚簇键将被添加到所有非聚簇索引，从而降低其效率。
SQL服务器将向非唯一聚簇索引添加一个uniquifier，使它们（以及所有非聚簇索引）更加宽泛。
如果这些索引使用的空间不是您的问题，那么您应该考虑聚簇索引键的值是否不断增加（或减少），就好像它不是，您将获得页面拆分和碎片肯定会伤害你的插入物。
如果您可以检查不同索引策略对正常查询的影响，那么在测试系统中设置它可能是值得的。