2009-12-18 5 views
1

Disons que nous avons une table [Valorisations] contenant plusieurs valeurs par date et par fonds:
-FundId
-ValDate
-Value1
-Value2 ...MS Access: optimisation index

Le La clé primaire est évidemment FundId + ValDate.
J'ai également indexé le champ ValDate car je demande souvent des valeurs à une date spécifique.

Ma question est la suivante: est-ce que je devrais également créer un index spécifique pour le FundId, ou MsAccess est-il assez intelligent pour employer la clef primaire en interrogeant sur un FundId spécifique?

Répondre

4

La clé primaire est évidemment FundId + ValDate

Dans quel ordre? Et comment accédez-vous à vos données?

Le moteur de base de données Access utilise le PRIMARY KEY comme index cluster. Si vous avez fait ce

PRIMARY KEY (FundId, ValDate)

alors vous obtiendrez un autre ordre sur le disque que si vous avez fait ce

PRIMARY KEY (ValDate, FundId)

Pour afficher l'ordre des colonnes du PK lorsque vous utilisez l'accès GUI (au cas où vous n'utilisiez pas DDL SQL pour créer le PRIMARY KEY): en mode Création de table, cliquez sur le bouton Index ou activez les index dans le menu Affichage. La liste affichera tous les index, et pour les champs multiples, elle montrera l'ordre, que vous pouvez modifier.

L'ordre des colonnes dans l'index clusterisé est important car il définit le seul et unique index physique pour la table, votre index uber pour ainsi dire.

(ValDate, FundId) favorisera BETWEEN (ou équivalent) prédicats ou GROUP BY sur ValDate par exemple. La plage de dates interroge le retour de plusieurs fonds.

(FundId, ValDate) ancien peut faveur des requêtes spécifiques fonds ... ou peut encourager les verrous de page, selon la façon dont les valeurs sont générées ....

Vous devriez maintenant être obtenir l'impression que les problèmes de performance est il y a beaucoup de variables impliquées: comment le PK a été défini, la génération des valeurs clés, combien de fois vous compactez le fichier, votre stratégie de verrouillage (par exemple niveau de page ou niveau de ligne?), environnement de haute ou basse activité, etc. la nature des requêtes que vous exécutez sur la table (par exemple par date ou par clé?)

êtes-vous sûr que Access prend en charge les index en cluster?

Bien sûr et voici quelques articles saillants sur MSDN:

New Features in Microsoft Jet Version 3.0 « Compacter la base de données se traduit désormais dans les indices étant stockés dans un format index cluster Alors que l'index cluster n'est pas maintenue jusqu'à ce que. compacte suivante, les performances sont encore améliorées.Ceci diffère de Microsoft Jet 2.x où les lignes de données ont été stockées de la façon dont elles ont été entrées.La nouvelle méthode compacte à clé en cluster est basée sur la clé primaire de la table.Les nouvelles données entrées seront dans l'ordre du temps. "

Defragment and compact database to improve performance in Microsoft Access « Si une clé primaire existe dans la table, le compactage des restaurations enregistrements de la table dans leur ordre de clé primaire. Cela fournit l'équivalent de non entretenus index cluster, et fait les capacités de lecture anticipée du moteur de base de données Microsoft Jet beaucoup plus efficace ... La vitesse de requête sera considérablement améliorée, car ils travaillent maintenant avec des données qui ont été réécrites dans les tables dans des pages contiguës.L'analyse de pages séquentielles est beaucoup plus rapide que l'analyse de pages fragmentées. "

How To Optimize Queries in Visual Basic « Cet article suppose que vous utilisez le moteur de base de données Microsoft Jet ... En tant que votre base de données augmente, il deviendra fragmenté. Compactage écrit toutes les données dans un tableau en pages contiguës sur le disque dur, l'amélioration des performances des analyses séquentielles. "

Information about query performance in an Access database « Lorsque vous compacter votre base de données, vous pouvez accélérer les requêtes. Lorsque vous compacter votre base de données, les enregistrements de la table sont réorganisées afin que les enregistrements résident dans des pages de base de données adjacentes qui sont commandés par la clé primaire de la table Cela améliore les performances des analyses séquentielles des enregistrements dans la table car seul le nombre minimum de pages de base de données doit maintenant être lu pour récupérer les enregistrements souhaités.

+0

Merci pour ces remarques détaillées, un jour quand. Mais êtes-vous sûr qu'Access supporte les index clusterisés? –

+0

oui, voir modifier pour répondre. – onedaywhen

+0

@onedaywhen Après avoir relu mon article, je pense que vous aviez raison de dire que la citation originale ne couvrait pas implicitement les index à plusieurs colonnes. J'ai supprimé la réponse pour éviter toute confusion. –

1

Pas besoin de mettre un index sur la colonne FundId. L'accès est assez intelligent pour utiliser le PK dans la situation que vous avez décrite.

BTW, est-ce que FundId est unique? Si c'est le cas, il n'est pas nécessaire d'inclure ValDate également.

+0

Ceci est en fait assez connu, et découle du fait que le PK est un index clusterisé, et donc écrit dans l'ordre de la première colonne. Gardez à l'esprit, cependant, que si vous avez défini l'intégrité relationnelle entre la 2ème colonne de votre PK et le PK d'une autre table, Jet/ACE crée un index caché, dans ce cas, vous n'avez pas besoin de créer un index, car il ne fera que dupliquer l'index caché que Jet/ACE crée à des fins de RI. –

+0

Pas besoin de créer un index mais ça ne fait pas de mal non plus en prenant plus de place. –

+0

@David W. Fenton: "si vous avez défini l'intégrité relationnelle entre la 2ème colonne de votre PK et le PK d'une autre table, Jet/ACE crée un index caché" - vous devez savoir que vous pouvez spécifier "NO INDEX" lors de la création de la clé "FOREIGN KEY" via SQL DDL en mode de requête ANSI-92. – onedaywhen