SQL Server: colonne Date de l'index dans une table de journal

Exemple Tableau:SQL Server: colonne Date de l'index dans une table de journal

CREATE TABLE Log (
    logID int identity 
    logDate datetime 
    logText varchar(42) 
)

LOGID est déjà indexé car il est une clé primaire, mais si vous deviez interroger ce tableau vous voudrez probablement utiliser LogDate comme une contrainte. Cependant, logID et logDate vont être dans le même ordre car logDate sera toujours défini sur GETDATE().

Est-il logique de placer un index supplémentaire non cluster sur logDate, en tenant compte du fait que pour la table Log, il est important d'avoir des écritures rapides.

Source

2009-10-06 SurroundedByFish

Faire un LogDate d'index ordonné en clusters, LOGID (dans cet ordre). A mesure que la date et l'heure "augmentent", cela ne devrait pas coûter plus cher. logID vous évite d'insérer deux entrées de journal en même temps (pourrait se produire)

Source

2009-10-06 12:43:29 Arthur

Comment implémentez-vous quelque chose comme ça? Déclarez-vous les deux colonnes en tant que clé primaire ou ignorez le PK et créez l'index avec une vérification unique sur logID? – SurroundedByFish

1) Laisser l'ID de journal comme clé primaire (ceci n'est pas un index). 2) Supprimer l'index clusterisé actuel sur IDlog 3) Créer un index clusterisé sur logDate, idID 4) éventuellement créer un index unique sur logID (si vous avez besoin d'accéder à logID) – Arthur

Je ne pouvais pas créer un index clusterisé lorsqu'un PK avait déjà créé automatiquement et je ne pouvais pas laisser tomber l'index tant que le PK existait. Cependant, j'ai réussi à le faire en créant l'index pour les deux coluns avant d'ajouter la contrainte PK sur l'ID. – SurroundedByFish

Si vous avez beaucoup de recherche avec un

WHILE LogDate > ......

(ou quelque chose de similaire) article - oui, par tous les moyens! L'index clusterisé sur le LogID n'aidera pas si vous sélectionnez par date - donc si c'est une opération commune, un index non-clustered sur la date aidera certainement beaucoup.

Marc

Source

2009-10-06 12:30:25

Ou, en effet, faire de l'index sur LogDate l'index cluster, si ce sera le principal moyen de localiser les lignes –

Étant donné la précision de datetime l'index clusterisé est peu susceptible d'être unique s'il est sur LogDate seul, SQL sera forcé d'ajouter un uniquificateur de 4 octets qui sera un gaspillage étant donné que le LogId pourrait être ajouté au même coût. – Andrew

Arthur est sur place avec comme considérant l'index clusterisé sur logdate, logid puisque vous risquez de rencontrer des doublons dans la fenêtre de la précision datetime (3.33 ms sur SQL 2005).

Je considérerais également à l'avance si la table va être grande et devrait utiliser le partitionnement de table pour permettre au journal d'avoir une fenêtre glissante et d'anciennes données supprimées sans avoir besoin d'instructions de suppression de longue durée. Tout dépend de la quantité d'enregistrements de journal et si vous avez l'édition d'entreprise.

Source

2009-10-06 13:03:35 Andrew

SQL Server: colonne Date de l'index dans une table de journal

Répondre

Questions connexes