Первичный ключ, очевидно,
FundId + ValDate
В каком порядке? И как вы получаете доступ к своим данным?
Access Database Engine использует PRIMARY KEY в качестве кластеризованного индекса. Если вы сделали это
PRIMARY KEY (FundId, ValDate)
тогда вы получите другой порядок на диске, чем если бы вы сделали это
PRIMARY KEY (ValDate, FundId)
Чтобы показать порядок столбцов в ПК при использовании графического интерфейса доступа (если вы не использовали SQL DDL для создания PRIMARY KEY): в представлении конструктора таблицы нажмите кнопку «Индексы» или включите индексы в меню Вид. В списке будут показаны все индексы, а для нескольких полей - порядок, который вы можете изменить.
Порядок столбцов в кластеризованном индексе важен, потому что он определяет один-единственный физический индекс для таблицы, ваш убер-индекс как бы.
(ValDate, FundId) будет отдавать предпочтение BETWEEN (или эквивалентным) предикатам или GROUP BY на ValDate, например. диапазон дат запросов, возвращающих несколько средств.
(FundId, ValDate) прежний может поддерживать запросы для конкретных фондов ... или может поощрять блокировки страниц, в зависимости от того, как генерируются значения ....
Теперь у вас должно сложиться впечатление, что с проблемами производительности связано много переменных: как определен PK, генерация значений ключей, как часто вы уплотняете файл, ваша стратегия блокировки (например, уровень страницы или уровень строки?), среда высокой или низкой активности и т. д. Не говоря уже о характере запросов, которые вы выполняете к таблице (например, по дате или по ключу?)
Вы уверены, что Access поддерживает кластеризацию
индексы?
Конечно, вот несколько заметных статей по MSDN:
Новые функции в Microsoft Jet версии 3.0
«Сжатие базы данных теперь приводит к тому, что индексы сохраняются в формате кластеризованного индекса. Хотя кластеризованный индекс не поддерживается до следующего сжатия, производительность все еще улучшается. Это отличается от Microsoft Jet 2.x, где хранятся строки данных как они были введены. Новый компактный метод кластеризованного ключа основан на первичном ключе таблицы. Новые введенные данные будут в порядке времени. "
Дефрагментация и сжатие базы данных для повышения производительности в Microsoft Access
«Если в таблице существует первичный ключ, сжатие восстанавливает записи таблицы в порядке их первичного ключа. Это обеспечивает эквивалент необслуживаемых кластерных индексов и делает возможности упреждающего чтения ядра базы данных Microsoft Jet гораздо более эффективными ... Скорость запросов будет значительно увеличена, поскольку теперь они работают с данными, которые были перезаписаны в таблицы на смежных страницах. Сканирование последовательных страниц намного быстрее, чем сканирование фрагментированных страниц. "
Как оптимизировать запросы в Visual Basic
«В этой статье предполагается, что вы используете ядро базы данных Microsoft Jet ... По мере роста вашей базы данных она будет фрагментирована. Сжатие записывает все данные в таблице на смежные страницы на жестком диске, улучшая производительность последовательного сканирования».
Информация о производительности запросов в базе данных Access
«При сжатии базы данных вы можете ускорить запросы. При сжатии базы данных записи таблицы реорганизуются таким образом, чтобы записи находились на смежных страницах базы данных, упорядоченных по первичному ключу таблицы. Это повышает производительность последовательное сканирование записей в таблице, потому что теперь нужно только минимальное количество страниц базы данных, чтобы получить нужные записи. "