我们有一个非常大的数据库，并且一直在使用我们想要摆脱的分片。每当一个表变得非常大时，分片就会起作用，我们启动一个与前一个表具有相同架构的新表，并在另一个表中保留一个数字，以帮助我们找到数据在哪个表中。这是一个繁琐的手动过程，并且意味着我们的数据分布在 N 个不同的表中，所有表都具有相同的模式。
我们正在尝试的想法是通过使用索引来消除对分片的需求。我们的数据查找查询不使用唯一键，并且返回的许多记录具有跨列的相同值。
下面说明了我们对特定表的许多查找选择，带 * 的字段表示该字段可能在选择中，也可能不在选择中。
where 子句：scheduled_test、*script、*label、*error_message
组/顺序：messenger_id、时间片、脚本、标签、error_message、step_sequence、*adapter_type
我的想法是我不想创建包含所有这 11 个字段的索引。相反，我选择了其中 3 个似乎更常用的，包括始终在 where 子句中的那个。我读过建议不要有太多字段的索引太宽。我还听说优化器将首先使用索引字段，并且即使 MSDN 声明唯一索引是最大的优势，具有非唯一索引的情况并不少见。这不是我们数据的设计方式。我意识到 SQL 会在索引中添加一些内容以使其独一无二，但这对于我们的目的似乎无关紧要。
当我在 sql server management studio 中查看类似于我们可能运行的查询的执行计划时，它说“聚集索引查找成本 100%”，但它使用的是我创建的聚集索引，所以我希望这个优于仅作为生成主键的默认聚集索引（以前如何定义表）。我希望我在这里所拥有的与我们的分片方法一样好或更好，并且将消除对分片的需求。
我们确实一次向表中插入了大量数据，但是这些行在许多列中都具有相同的数据值，我认为它们甚至倾向于在最后插入。这些插入不与旧数据共享值，如果索引只有 3 列，希望这不会对插入造成很大的影响。
我所说的是否合理，或者我还应该研究或考虑什么？非常感谢，我对这些类型的索引问题不太熟悉，但一直在寻找各种网站并进行试验。