2009-12-18 2 views
1

Допустим, у нас есть таблица [Приблизительные], содержащий несколько значений для каждого дня и за фонд:
-FundId
-ValDate
-Value1
-Value2 ...MS Access: индекс оптимизации

В Первичный ключ, очевидно, FundId + ValDate.
Я также проиндексировал поле ValDate, так как часто запрашиваю значения в определенную дату.

Мой вопрос: должен ли я также создать определенный индекс для FundId, или достаточно MsAccess, чтобы использовать ключ Primary при запросе на определенный FundId?

ответ

4

Первичный ключ, очевидно FundId + ValDate

В каком порядке? И как вы получаете доступ к своим данным?

Механизм базы данных доступа использует PRIMARY KEY как кластерный индекс. Если вы сделали это

PRIMARY KEY (FundId, ValDate)

, то вы получите другой порядок на диске, чем если бы вы сделали это

PRIMARY KEY (ValDate, FundId)

Чтобы показать порядок столбцов в ПК при использовании доступа GUI (если вы не использовали SQL DDL для создания PRIMARY KEY): в представлении табличного дизайна нажмите кнопку «Индексы» или включите «Индексы» в меню «Вид». В списке будут показаны все индексы, а для нескольких полей - порядок, который вы можете изменить.

Порядок столбцов в кластерном индексе важен, потому что он определяет единственный и единственный физический индекс для таблицы, ваш индекс uber как есть.

(ValDate, FundId) будет поддерживать BETWEEN (или аналогичные) предикаты или GROUP BY на ValDate, например. запрос диапазона дат, возвращающий несколько фондов.

(FundId, ValDate) бывший может пользу фонда конкретных запросы ... или может стимулировать блокировки страниц, в зависимости от того, как генерируется значение ....

Вы должны теперь получать впечатление, что проблемы с производительностью является существует много переменных: как определяется ПК, генерация ключевых значений, как часто вы уплотняете файл, свою стратегию блокировки (например, уровень страницы или уровень строки?), высокую или низкую активность и т. д. Не говоря уже характер запросов, которые вы выполняете против таблицы (например, по дате или по ключу?)

Вы уверены, что Access поддерживает кластерные индексы ?

Конечно, и здесь некоторые характерные статьи на MSDN:

New Features in Microsoft Jet Version 3.0 «Сжатие базы данных в настоящее время приводит к индексам хранящихся в формате кластерного индекса-Хотя кластерный индекс не не поддерживается до тех пор. следующий компактный, производительность по-прежнему улучшена. Это отличается от Microsoft Jet 2.x, где строки данных были сохранены так, как они были введены. Новый компактный метод с кластеризованным ключом основан на первичном ключе таблицы. в порядке времени ".

Defragment and compact database to improve performance in Microsoft Access «Если существует первичный ключ в таблице, уплотняя восстановление записей таблицы в их первичный ключе порядка. Это обеспечивает эквивалент Non поддержанных кластерных индексов, и делает возможности чтения впереди ядра базы данных Microsoft Jet гораздо эффективнее ... Скорость запроса значительно повысится, потому что теперь они работают с данными, которые были переписаны в таблицы на смежных страницах. Сканирование последовательных страниц намного быстрее, чем сканирование фрагментированных страниц ».

How To Optimize Queries in Visual Basic «В данной статье предполагается, что вы используете ядро ​​базы данных Microsoft Jet ... По мере роста базы данных, он будет фрагментирован. Compacting записывает все данные в таблице в последовательные страницы на жестком диске, улучшая производительность последовательного сканирования ".

Information about query performance in an Access database «При сжатии базы данных можно ускорить запросы. При сжатии базы данных, записи таблиц перестраиваются так, что записи находятся в соседних страницах базы данных, которые упорядочены по первичному ключу таблицы Это улучшает производительность последовательных сканирований записей в таблице, потому что теперь нужно прочитать только минимальное количество страниц базы данных, чтобы получить нужные записи ».

+0

Спасибо за эти подробные замечания, позже. Но вы уверены, что Access поддерживает кластеризованные индексы? –

+0

Да, см. Изменение ответа. – onedaywhen

+0

@onedaywhen Aftert перечитывая мое сообщение, я думаю, вы были правы в том, что исходная цитата не косвенно охватывала индексы с несколькими столбцами. Я удалил ответ, чтобы избежать путаницы. –

1

Не нужно указывать индекс в столбце FundId. Доступ достаточно умен, чтобы использовать ПК в описанной вами ситуации.

BTW, является уникальным FundId? Если это так, нет необходимости включать ValDate.

+0

Это на самом деле довольно хорошо известно и следует из того факта, что ПК является кластеризованным индексом и, таким образом, записывается в порядке первого столбца. Однако имейте в виду, что если вы определили реляционную целостность между вторым столбцом вашего ПК и ПК другой таблицы, Jet/ACE создает скрытый индекс, поэтому в этом случае вам не нужно создавать индекс, потому что он просто дублирует скрытый индекс, создаваемый Jet/ACE для целей RI. –

+0

Не нужно создавать индекс, но это не повредит, заняв больше места. –

+0

@David W. Fenton: «Если вы определили реляционную целостность между вторым столбцом вашего ПК и ПК другой таблицы, Jet/ACE создает скрытый индекс» - вы должны знать, что вы можете указать «NO INDEX» при создании 'FOREIGN KEY' через SQL DDL в режиме запросов ANSI-92. – onedaywhen