Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Etrange recherche sur un des champs d'une clef primaire

2 réponses
Avatar
balmeyer
Bonjour,

Je constate une ph=E9nom=E8ne bizarre suite =E0 une requ=EAte sur un champs
contenu dans une clef primaire.

- la PK se constitue de trois champs :

- a numeric(9)
- b numeric (9)
- c int

La requ=EAte suivante est MOINS rapide que la seconde, alors que le
premier argument est un nombre et le second une cha=EEne (je pensais que
la conversion chaine / nombre ralentirait la t=E2che) :

select * from table where a =3D 55000 ;
select * from table where a =3D '55000' ;


J'attribue ce ph=E9nom=E8ne au fait que la clef primaire soit la
concat=E9nation de trois champs (dont le dernier est de nature
diff=E9rente), et donc se comporte un peu comme une cha=EEne de
caract=E8re. Suis dans le vrai ?

Autre ph=E9nom=E8ne :

Quand je fais
select * from table where a =3D 5 ;
le plan d'=E9xecution et :
Clustered Index Seek 100% ---> select 0%

Alors que si je fais
select * from table where a =3D 55000;
le plan est:
Clustered Index Seek Scan 91% ---> Parallelism/Gather stream 9% --->
Select 0%

L=E0 je suis perdu...


J'essaye donc de convertir explicitement l'argument dans la condition,
et =E7a donne :



select * from table where a =3D cast (55000 as numeric(9))
select * from table where a =3D cast(5 as numeric(99))
=3D=3D=3D > Clustered Index Seek 100% ---> select 0%

select * from table where a =3D cast (55000 as int)
select * from table where a =3D cast(5 as int)
=3D=3D=3D > Clustered Index Seek Scan 91% ---> Parallelism/Gather stream
9% ---> Select 0%

Qui peut m'=E9claire la dessus ? Merci beaucoup par avance.

2 réponses

Avatar
balmeyer
Oui je sais, c'est pas très sexy comme problème... :)
Mais vraiment personne pour avoir une petite idée ??
Avatar
Patrice
Pour le premier point, as tu essayé de lancer une deuxième exécution ? A mon
avis, la conversion est faite de toute façon une fois, est rapide et n'a à
mon avis qu'un impact très faible. Je pense que la différence que tu vois
est plutôt un problème de mise en cache des données (la première requête
mets en cache les données et la dexuième se contente de lectures en cache,
elle apparait donc plus rapide).




--

"balmeyer" a écrit dans le message de news:

Oui je sais, c'est pas très sexy comme problème... :)
Mais vraiment personne pour avoir une petite idée ??