我们有一个表，比如说，5 个索引（一个集群）。
问题：如果所有 5 个索引都以相同的确切字段开头，它是否会对优化器的性能产生负面影响——无论是速度还是索引选择的准确性？（所有其他条件相同）。
公司有人建议它可能对性能产生不利影响，因此需要对其中一个指数进行前两个字段的切换。
如果没有必要，我宁愿避免改变，因为他们没有用任何事实/推理来支持他们的断言，但是这个人足够资深和聪明，我倾向于认真考虑他的建议。
注意1：基本答案“为where子句和整体查询定制索引”对我没有帮助 - 将更改的索引是使用它的唯一查询的覆盖索引，因此其中字段的顺序将不影响IO量。我问了一个单独的 SO 问题只是为了确认这一断言。
注意 2：该字段是插入记录的日期，如果这很重要，表很大。它有大约 100 天的数据，每个日期的行数大约相等，第一个索引是从该日期字段开始的聚集索引。
如果有五个索引，优化器必须更多地考虑使用哪个索引。该成本通常并不算太糟糕，但这取决于您要询问的查询。原则上，一旦查询被优化，执行它所花费的时间应该大致相同。如果您正在为多种用途准备 SELECT 语句，那么这并不重要。如果每个查询都是重新准备并且从不重用，那么开销可能会拖累系统性能 - 特别是如果事实证明大多数查询实际使用哪个索引并不重要（当五个索引都共享相同的前导列）。
数据更改时还有维护成本 - 更新五个索引所花费的时间明显比一个索引要长，此外，五个索引使用的磁盘存储量大约是一个索引的五倍。
我不想代表你的高级同事说话，但我相信你误解了他所说的话，或者他表达的不够明确，让你理解。
设计不佳且性能不佳的表的突出之处之一是，它们上有许多索引，并且索引的前导列都是相同的。每一次。
因此，对于所有具有相同前导列的索引是否存在服务器成本的争论（争论过于孤立）是毫无意义的；问题在于设计不佳的桌子以多种方式暴露自己。这是每次访问的巨大服务器成本。我怀疑这就是你尊敬的同事的来源。
索引的单调列对于索引来说是非常糟糕的选择（理解，您至少需要一个）。但是，当您使用该单调列强制其他一些索引中的唯一性时，这将是无关紧要的（由于低基数，例如 SexCode），这对我来说是另一个危险信号。你只是强迫一个不相关的索引稍微相关）；除了单个覆盖查询之外，这些查询在通过主键进行最简单选择之外的任何内容上都表现不佳。
没有“覆盖索引”之类的东西，但我理解你的意思，你添加了一个索引，以便某个查询将作为覆盖查询执行。另一个标志。
我和米奇在一起，但我不确定你明白他的意思。
最后，单独回答你的问题，有五个索引与前导列都相同不会导致“性能问题”，超出由于糟糕的表格设计而导致的“性能问题”，但它会导致焦虑和不必要的体力劳动对于追查奇怪行为的开发人员，例如“为什么优化器使用 index_1 进行我的查询，但今天它使用的是 index_4？”。
您的语言始终如一（尤其是在评论中）显示出一种孤立地处理问题的方式。服务器和数据库的概念是，它是共享的中央资源，与隔离正好相反。孤立地“解决”的问题通常会对孤立空间之外的每个人造成负面的性能影响。
如果您真的希望完全解决问题，请发布 CREATE TABLE 语句。
我怀疑它会对 SELECT 性能产生任何重大影响。
但这可能意味着您可以重新组织这些索引（基于代表性查询工作负载）以更好地更有效地为查询提供服务。
我不熟悉 Sybase 的最新版本，但总的来说，对于所有 SQL 服务器，主要（并且几乎）唯一影响性能的索引是 INSERT、DELETE 和 UPDATE 查询。基本上，对数据库的每次更改都需要更新数据表本身（或聚集索引）以及所有索引。
对于 SELECT 查询，具有“太多”索引可能会对性能产生轻微影响，例如通过引入竞争硬盘页面进行缓存。但我怀疑在大多数情况下这将是一个重大问题。
事实上，所有这些索引中的第一列是日期，并且假设日期值通常是单调的，这是一件好事（关于 CRUD 操作），因为它将保持拆分/平衡索引表的需要一个最小的。（因为大多数插入在索引的末尾）。
此外，此表似乎足够小（“大”是一个相对词 ;-)），因此可以相对安全和轻松地进行一些实验，以更系统的方式断言性能问题，而不会对生产造成太大影响。（除非 10k 左右的记录非常宽或每秒查询率很高等。）