假设我们有一个[Valuations]表，其中包含每个日期和每个基金的几个值：
-FundId
-ValDate
-Value1
-Value2 ......
主键显然是FundId + ValDate 我还索引了ValDate字段，因为我经常查询特定日期的值。
我的问题是：我是否还应该为FundId创建一个特定的索引，或者MsAccess是否足够聪明，在查询特定的FundId时使用主键？
答案 0 :(得分：4)
主键显然是
FundId+ValDate
以哪种顺序？你如何访问你的数据？
Access数据库引擎使用PRIMARY KEY作为聚簇索引。如果你这样做了
PRIMARY KEY (FundId, ValDate)
然后你会得到一个不同的订单，而不是你做这个
PRIMARY KEY (ValDate, FundId)
在使用Access GUI时显示PK中列的顺序（如果您没有使用SQL DDL创建PRIMARY KEY）：在表设计视图中，单击“索引”按钮，或启用“视图”菜单中的索引。该列表将显示所有索引，对于多个字段，它会显示您可以更改的顺序。
聚集索引中列的顺序很重要，因为它定义了表的唯一物理索引，你的uber索引。
(ValDate, FundId)会支持BETWEEN（或等效）谓词或GROUP BY ValDate，例如返回多个基金的日期范围查询。
(FundId, ValDate)前可能支持基金特定查询...或者可能会鼓励页面锁定，具体取决于值的生成方式....
您现在应该得到这样的印象：性能问题涉及到许多变量：PK的定义方式，关键值的生成，压缩文件的频率，锁定策略（例如页面级别或行级别？），高或低活动环境等。更不用说针对表运行的查询的性质（例如按日期或按键？）
您确定Access支持群集 索引？
当然，以下是MSDN上的一些重要文章：
New Features in Microsoft Jet Version 3.0 “压缩数据库现在导致索引以聚簇索引格式存储。虽然聚簇索引在下一个压缩程序之前不会被维护，但性能仍然有所提高。这与Microsoft Jet 2.x不同，后者存储了数据行它们的输入方式。新的聚类密钥紧凑方法基于表的主键。输入的新数据将按时间顺序排列。“
Defragment and compact database to improve performance in Microsoft Access “如果表中存在主键，则压缩会将表记录还原为主键顺序。这提供了相当于非维护的群集索引，并使Microsoft Jet数据库引擎的预读功能更加高效......查询速度将得到显着提升，因为它们现在正在使用已经重写到连续页面中的表的数据。扫描顺序页面比扫描碎片页面快得多。“
How To Optimize Queries in Visual Basic “本文假设您使用的是Microsoft Jet数据库引擎......随着数据库的增长，它将变得支离破碎。压缩将表中的所有数据写入硬盘上的连续页面，从而提高了顺序扫描的性能。” / p>
Information about query performance in an Access database “当您压缩数据库时，可以加快查询速度。压缩数据库时，会重新组织表的记录，以便记录驻留在由表的主键排序的相邻数据库页中。这样可以提高性能。表中记录的顺序扫描，因为现在只需要读取最少数量的数据库页来检索所需的记录。“
答案 1 :(得分：1)
无需在FundId列上添加索引。访问足够智能，可以在您描述的情况下使用PK。
BTW，是FundId的独特之处吗？如果是这样，也不需要包括ValDate。