Discussion :

[cristophe0071983]

bonjour a tous

Dans le but de chercher plus performance dans une base de donnée qui serai mis en production

je cherche a faire une petit comparaison sur deux sénariaux

j'explique si j'ai un table qui contient un clé primaire et une contraint d’unicité

le clé primaire c'est du varchar(50) et le contraint d'unicité pointe sur deux colonne de type varchar(10) chaqu'un

dans ce scénario est 'il préférer de mettre le contraint primary key en nonclustered et le contraint d'unicité avec un index cluster ou je fait

l’inverse qui est normalement faite par défaut

Quel est le plus performant entre ces deux sénariaux

merci pour vos remarques

[SQLpro]

bonjour a tous

Dans le but de chercher plus performance dans une base de donnée qui serai mis en production

je cherche a faire une petit comparaison sur deux sénariaux

j'explique si j'ai un table qui contient un clé primaire et une contraint d’unicité

le clé primaire c'est du varchar(50) et le contraint d'unicité pointe sur deux colonne de type varchar(10) chaqu'un

dans ce scénario est 'il préférer de mettre le contraint primary key en nonclustered et le contraint d'unicité avec un index cluster ou je fait

l’inverse qui est normalement faite par défaut

Quel est le plus performant entre ces deux sénariaux

merci pour vos remarques

Aucune des scénarios (notez l'orthographe au passage) ne vous donnera des performances !

Une clef primaire de type littéral et en sus d'une aussi grande longueur est hautement stupide pour 5 raisons :
1) le VARCHAR(50) c'est au plus 52 octets, soit 7 passes dans un processeur 64 bits pour lire la clef !!! donc 7 fois plus long qu'un INT
2) la clef étant sémantique en cas de modification de la clef il faut modifier toutes les clefs étrangères pointant vers la référence (bonjour la durée des transactions bloquantes)
3) un littéral suppose une collation (façon de gérer les casse, les accents...) toute chose qui entraine de l'extra overhead qu'un type INT n'a pas !
4) en mémoire, pour certaines calculs (tri, groupage...) le moteur doit "aligner" les littéraux à une longueur standard. Si vous avez par exemple 1 millions de lignes l'alignement à 50 octets va vous couter 48 Mo... Au lieu de 8 Mo
5) si votre PK est CLUSTERED tous les index secondaire vont avoir cette référence de ligne ce qui augmente artificiellement de 48 octets toutes les lignes de tous les index....

A +

[olivtone]

UNE PK Clustered sur un identity je pense est le top niveau perfomance (petit, stable, et incremental)

[mikedavem]

UNE PK Clustered sur un identity je pense est le top niveau perfomance (petit, stable, et incremental)

Effectivement. Mais il peut aussi arriver dans certains cas que l'insertion monotone dans la dernière page de l'index devienne problématique dans des environnements concurrentiels (problématique de verrouillage de bas niveau - les fameux latches sur la dernière page de l'index). Paradoxalement l'identité ne devient plus la meilleure solution dans ce cas mais bon nous sommes plus dans l'exception que dans la généralité ici

++

[SQLpro]

Effectivement. Mais il peut aussi arriver dans certains cas que l'insertion monotone dans la dernière page de l'index devienne problématique dans des environnements concurrentiels (problématique de verrouillage de bas niveau - les fameux latches sur la dernière page de l'index). Paradoxalement l'identité ne devient plus la meilleure solution dans ce cas mais bon nous sommes plus dans l'exception que dans la généralité ici

++

Aujourd'hui ce n'est plus vraiment le cas, car le système peut travailler en parallèle sur plus de 32 threads simultanés.

Si tu arrives à me le mettre en évidence je suis preneur !

A +

[escartefigue]

Aucune des scénarios (notez l'orthographe au passage) ne vous donnera des performances !

Une clef primaire de type littéral et en sus d'une aussi grande longueur est hautement stupide pour 5 raisons :
1) le VARCHAR(50) c'est au plus 52 octets, soit 7 passes dans un processeur 64 bits pour lire la clef !!! donc 7 fois plus long qu'un INT
2) la clef étant sémantique en cas de modification de la clef il faut modifier toutes les clefs étrangères pointant vers la référence (bonjour la durée des transactions bloquantes)
3) un littéral suppose une collation (façon de gérer les casse, les accents...) toute chose qui entraine de l'extra overhead qu'un type INT n'a pas !
4) en mémoire, pour certaines calculs (tri, groupage...) le moteur doit "aligner" les littéraux à une longueur standard. Si vous avez par exemple 1 millions de lignes l'alignement à 50 octets va vous couter 48 Mo... Au lieu de 8 Mo
5) si votre PK est CLUSTERED tous les index secondaire vont avoir cette référence de ligne ce qui augmente artificiellement de 48 octets toutes les lignes de tous les index....

A +

et 6) le varchar impose dans certains cas de mise à jour des déplacements physiques des pages de données data et/ou index, ce qui peut être très couteux en perfs

[SQLpro]

et 6) le varchar impose dans certains cas de mise à jour des déplacements physiques des pages de données data et/ou index, ce qui peut être très couteux en perfs

7) le volume globale de la base sera beaucoup plus important et va rejaillir sur les processus de maintenance et de sauvegarde qui seront notablement plus longs.

A +