Exception faite des index unique filtrées, il n’y aucune différence en termes de performances entre l’ajout d’un index unique, et l’ajout d’une contrainte d’unicité (qui est elle-même supportée par un index unique).
La contrainte d’unicité permet de signifier que l’intégrité des données est le but, alors que le but premier d’un index est l’accélération des requêtes.
La majorité des index unique étant ajoutés pour renforcer l’intégrité des données, voici donc un script pour trouver tous les index unique non filtrés qui n’ont pas de contrainte d’unicité.
Archives pour la catégorie Indexation
Etude de table : retourner les caractéristiques des statistiques et index d’une table (ou vue indexée)
Voici un script qui retourne :
– l’en-tête des statistiques d’une table
– la liste des colonnes qui participent à la statistique, ou des colonnes clé de l’index (incluses et filtrées)
– le vecteur de la statistique, qui permet de connaître sa sélectivité
– optionnellement, le niveau de fragmentation des index
– le nombre d’utilisation des index
– la date de dernière mise à jour de chaque statistique scrutée par le script
Différence entre ALTER INDEX … REBUILD et ALTER INDEX … REORGANIZE
Après avoir vu ce que sont la fragmentation interne et externe d’un index, voyons les différences entre les options REBUILD et REORGANIZE de l’instruction ALTER INDEX (ou respectivement DBCC DBREINDEX ou DBCC INDEXDEFRAG sous SQL Server 2000)
Lire la suite
Lister les caractéristiques des indexes sous SQL Server 2005 et 2008
Voici une requête qui nous permet de retrouver pour tout index :
– la liste de ses colonnes clé
– la liste de ses colonnes incluses
– la définition de son filtre
– le script de création de cet index
Rechercher les index inutiles
Si les index représentent l’optimisation la plus simple à mettre en place, on souhaite néanmoins conserver le minimum d’entre-eux, car leur maintenance lors de l’exécution de requêtes de modifications de données (INSERT, UPDATE, DELETE) peut être coûteuse, surtout sur des tables volumineuses.
Voyons comment collecter cette information …
Lire la suite
Lister les colonnes des index d’une base de données
Voici une petite requête qui permet de lister les colonnes de tous les index d’une base de données, avec leur type et l’ordre des colonnes dans la clé de l’index :
Lire la suite
Une procédure pour connaître l’état physique et l’utilisation des index
Voici une petite procédure stockée qui permet de connaître l’état physique des index (nombre de pages du niveau feuille, fragmentation et taux d’utilisation des pages) en même temps que la façon dont ils sont utilisés (nombres de seeks et de scans, …).
Elle est utilisable pour collecter ces statistiques sur l’ensemble d’une base de données, ou bien sur une table en particulier
Lire la suite
Une procédure stockée pour défragmenter les indexes sous SQL Server 2005 et ultérieur
Voici une petite procédure stockée que l’on peut exécuter régulièrement dans un job pour défragmenter les indexes de toutes les bases de données, en fixant les seuils de nombre de page et de pourcentage moyen de fragmentation
Vérifier l’unicité d’une position avec le type GEOGRAPHY sous SQL Server 2008
SQL Server 2008 a introduit de nombreux nouveaux types de données, dont le type de données géographiques GEOGRAPHY.
Ce n’est pas un type habituel, puisque c’est un type CLR.NET intégré à SQL Server.
L’avantage présenté par l’intégration de ce type est l’ensemble des méthodes standard « livrées » avec ce type, qui permettent d’extraire très simplement une latitude (attribut Lat), une longitude (attribut Long), ou encore de connaître la distance entre deux points géographiques avec la méthode STDistance.
Mais il devient alors plus complexe de garantir l’unicité de positions dans une table où l’on stocke la celle de plusieurs villes.
En effet, si une colonne de ce type est spécifiée comme clé d’une contrainte d’unicité, le moteur de base de données SQL Server lève une exception.
Est-il possible de contourner ce problème ?
Vérifier l’unicité de tuples NULLables avec les index filtrés sous SQL Server 2008
Toute contrainte d’unicité entraîne la création implicite d’une index unique sur la table, dont la clé est constituée des colonnes spécifiées dans la contrainte d’unicité.
Or, lors de l’insertion d’une nouvelle ligne ou de la modification d’une des colonnes constituant la clé unique, SQL Server considère NULL comme une valeur.
Cela est faux puisque NULL n’est pas une valeur : c’est l’absence de valeur.
Avec SQL Server 2008 ont été introduits les index filtrés, qui permettent de spécifier les lignes candidates à l’indexation, par l’ajout d’une simple clause WHERE.
Dès lors, il est possible de contourner le problème posé par les contraintes d’unicité en se servant de ce type d’index …