假设我们有一个 [Valuations] 表，其中包含每个日期和每个基金的多个值：
-FundId
-ValDate
-值1
-值2...
主键显然是 FundId+ValDate。
我还索引了 ValDate 字段，因为我经常查询特定日期的值。
我的问题是：我应该也为 FundId 创建一个特定的索引，还是 MsAccess 足够聪明以在查询特定 FundId 时使用主键？
【问题讨论】：
标签： database ms-access database-design ms-access-2007
主键显然是
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 on ValDate，例如返回多个资金的日期范围查询。
(FundId, ValDate) 前可能支持特定的查询...或者可能鼓励页面锁定，具体取决于值的生成方式....
您现在应该得到的印象是，性能问题涉及许多变量：PK 的定义方式、键值的生成、压缩文件的频率、锁定策略（例如页面级别或行级别？），高或低活动环境等。更不用说您对表运行的查询的性质（例如按日期还是按键？）
您确定 Access 支持集群 索引？
当然，这里有一些 MSDN 上的重要文章：
New Features in Microsoft Jet Version 3.0 “现在压缩数据库会导致索引以聚集索引格式存储。虽然聚集索引直到下一次压缩才会维护，但性能仍然有所提高。这与 Microsoft Jet 2.x 不同，其中存储了数据行输入的方式。新的 clustered-key compact 方法基于表的主键。输入的新数据将按时间顺序排列。"
Defragment and compact database to improve performance in Microsoft Access “如果表中存在主键，则压缩会将表记录恢复为其主键顺序。这提供了相当于非维护聚集索引，并使 Microsoft Jet 数据库引擎的预读功能更加高效......查询速度将显着提高，因为它们现在正在处理已重写到连续页面中的表的数据。扫描连续页面比扫描碎片页面快得多。”
How To Optimize Queries in Visual Basic “本文假设您使用的是 Microsoft Jet 数据库引擎...随着您的数据库增长，它会变得碎片化。压缩将表中的所有数据写入硬盘上的连续页面，从而提高顺序扫描的性能。”
Information about query performance in an Access database “压缩数据库时，可以加快查询速度。压缩数据库时，会重新组织表的记录，以便记录驻留在按表的主键排序的相邻数据库页面中。这提高了对表中的记录进行顺序扫描，因为现在只需读取最少数量的数据库页面即可检索您想要的记录。”
【讨论】：
无需在 FundId 列上放置索引。 Access 足够智能，可以在您描述的情况下使用 PK。
顺便说一句，FundId 是唯一的吗？如果是这样，则无需同时包含 ValDate。
【讨论】：
FOREIGN KEY 时指定NO INDEX。