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