是否有多个索引都以相同的列开头会对Sybase优化器的速度或准确性产生负面影响？

Question

我们有一个表，例如5个索引（一个聚集）。

问题：它是否会以某种方式对优化器性能产生负面影响 - 无论是速度还是索引选择的准确性 - 如果所有5个索引都以相同的精确字段开头？ （所有其他条件相同）。

该公司的某人建议它可能对性能产生不利影响，因此其中一个指数需要切换前两个字段。

如果没有必要，我宁愿避免改变，因为他们没有用任何事实/推理来支持他们的断言，但是这个人是高级和聪明的，我倾向于认真考虑他的建议。

注1：基本答案“定制where子句和整体查询的索引”对我没有帮助 - 将要更改的索引是使用它的唯一查询的覆盖索引，因此字段的顺序在其中不会影响IO数量。 I have asked a separate SO question just to confirm that assertion.

注2：该字段是插入记录的日期，如果这很重要，则表格非常大。它有大约100天的数据，大约相等于每个日期的行数，第一个索引是从该日期字段开始的聚簇索引。

Answer 1

如果有五个索引，优化器必须更多地考虑使用哪个索引。这个成本通常不是太糟糕，但这取决于你问的问题。原则上，一旦查询被优化，执行它所花费的时间应该大致相同。如果您准备SELECT语句用于多种用途，那将无关紧要。如果每个查询都重新准备好并且从不重用，那么开销可能会对系统性能造成拖累 - 特别是如果事实证明哪些索引实际上用于大多数查询并不重要（当中有一个中等强度的危险时）五个索引都共享相同的前导列。）

数据更改时还有维护成本 - 更新五个索引的时间明显长于一个索引，而且五个索引的磁盘存储空间大约是一个。

Answer 2

我不想为你的高级同事发言，但我相信你误解了他所说的话，或者他没有明确表达自己的理解。

设计不佳，表现不佳的表突出的一点是，它们上面有许多索引，索引的前导列都是一样的。每一次。

因此，对于所有具有相同前导列的索引，服务器成本是否无关紧要（辩论过于孤立）;问题是设计糟糕的桌子以无数种方式暴露自己。这是每次访问的巨大服务器成本。我怀疑那是你尊敬的同事来自的地方。

索引的单调列对于索引来说是非常差的选择（理解，您至少需要一个）。但是当你使用那个单调列来强制其他索引中的唯一性时，否则会无关紧要（由于基数较低，例如SexCode），这对我来说是另一个危险信号。你只是强迫一个不相关的索引有点相关）;除了单个覆盖的查询之外，查询在通过主键的最简单选择之外的任何事情上都表现不佳。

没有“覆盖索引”这样的东西，但我理解你的意思，你已经添加了一个索引，以便某个查询将作为覆盖查询执行。另一面旗帜。

我和米奇在一起，但我不确定你是不是他的漂移。

最后，单独回答你的问题，有五个索引与前导列完全相同不会导致“性能问题”，超出你已经拥有的由于糟糕的表设计，但它会引起焦虑和开发人员追逐奇怪行为的不必要的手工劳动，例如“为什么优化器使用index_1作为我的查询，但今天它正在使用index_4？”。

您的语言一致（特别是在评论中）显示了一种孤立地处理问题的方式。服务器和数据库的概念是它是一个共享的中央资源，与隔离相反。孤立地“解决”的问题通常会对隔离空间之外的每个人产生负面的性能影响。

如果您真的想完全处理问题，请发布CREATE TABLE语句。

Answer 3

我不熟悉Sybase的最新版本，但通常对所有SQL服务器都很熟悉， 主要（和几乎）仅性能影响索引具有INSERT，DELETE和UPDATE查询。基本上，对数据库的每次更改都需要更新数据表本身（或聚簇索引）以及所有索引。

关于SELECT查询，具有“太多”索引可能会对性能产生轻微影响，例如通过引入竞争硬盘页面进行缓存。但我怀疑这在大多数情况下都是一个重要的问题。

事实上，所有这些索引中的第一列是日期，并假设日期值通常是单调的进展，这是一个积极的事情（关于CRUD操作），因为它将保持分裂/平衡的需要索引表到最小。 （因为大多数插入在索引的末尾）。

此表似乎足够小（“大”是一个相对的词;-)），可以相对安全和轻松地进行一些实验以更系统地断言性能问题，而不会干扰生产。 （除非10k左右的记录很宽或者每秒查询率很高等等。）

Answer 4

我怀疑它会对SELECT性能产生重大影响。

但这可能意味着您可以重新组织这些索引（基于代表性的查询工作负载），以便更有效地提供查询。