我们有一个大表，有几个索引（比如I1-I5）。
使用模式如下：
应用程序A：所有选择查询100％使用索引I1-I4（假设它们的设计足够好，以至于它们永远不会使用I5）。
应用程序B：只有一个选择查询（经常运行），其中包含6个字段，并为其创建了第五个索引I5作为覆盖索引。
涵盖索引的前2个字段是日期和安全ID。 该表包含~100个日期的行（按日期顺序，由聚簇索引I1强制执行），以及数万个安全标识符。
问题：覆盖索引中列的顺序是否会影响应用程序B中选择查询的性能？
即如果我们切换索引的前两个字段（日期和安全ID），查询性能是否会发生变化？ 如果我们切换最后一个字段之一，查询性能是否会改变？
我假设逻辑IO不受覆盖索引中任何字段顺序的影响（尽管我不是100％肯定）。
但是会有其他性能影响吗？ （优化器速度，缓存等......）
问题是版本通用，但如果重要，我们使用Sybase 12。
不幸的是，该表非常庞大，实际上在实践中改变指数并且定量地确认变化的影响是非常困难的。
答案 0 :(得分：1)
这取决于。如果您有一个WHERE子句，如下所示，您将在（security_ID，date_column）上的索引中获得比converse更好的性能：
WHERE date_column BETWEEN DATE '2009-01-01' AND DATE '2009-08-31'
AND security_ID = 373239
如果你有一个WHERE子句，如下所示，你会在（date_column，security_ID）的索引上获得比converse更好的性能：
WHERE date_column = DATE '2009-09-01'
AND security_ID > 499231
如果您有一个WHERE子句，如下所示，那么首先出现哪一列真的无关紧要：
WHERE date_column = DATE '2009-09-13'
AND security_ID = 211930
我们需要了解索引中其他列的选择性和条件，以了解是否有其他方法可以组织索引以获得更高的性能。
就像您的问题是版本通用一样，我的答案是DBMS-generic。
答案 1 :(得分：1)
不幸的是，该表非常庞大，实际上在实践中改变指数并且定量地确认变化的影响非常困难。
问题是不表的大小。数百万行对Sybase来说毫无意义。
问题是缺少测试系统。