Discussion :

[olivtone]

Hello a Tous

Avez vous des retours d'experience concernant les fonctions SQL comme le CONVERT ou le CAST, que si elles etaient dans le WHERE cela prenait pas l'index (Des DBA m'on dit ca)

J'ai fait des tests de mon coté, j'ai pas ce genre d'erreur lol

J'ai lu aussi dans le livre SQL 2014 (SQL Server 2014 : Développer et administrer pour la performance) que le CONVERT est 30 % plus gourmand que le CAST, mais sans exemple; peut on avoir un retour d'experience?

Derniere question :

Est il possible de voir la liste des dernieres fonctions SQL apparus sur SQL 2012 et 2014 (comme EOMONTH, FORMAT etc....)

Merci a vous et bonne journée

[aieeeuuuuu]

Bonjour,

Avez vous des retours d'experience concernant les fonctions SQL comme le CONVERT ou le CAST, que si elles etaient dans le WHERE cela prenait pas l'index (Des DBA m'on dit ca)

C'est parfois vrai. Si la fonction porte sur la colonne indexée, cela peut empêcher l'utilisation des index sur cette colonne.

J'ai fait des tests de mon coté, j'ai pas ce genre d'erreur lol

Quels tests avez vous fait ?
SQL Server est quand même capable d'utiliser les index pour certaines opérations, comme par exemple un DATETIME casté en DATE.

J'ai lu aussi dans le livre SQL 2014 (SQL Server 2014 : Développer et administrer pour la performance) que le CONVERT est 30 % plus gourmand que le CAST, mais sans exemple; peut on avoir un retour d'experience?

Je suis étonné de cette affirmation. En effet, un CAST est implicitement transcris en un CONVERT lors de l'élaboration du plan d’exécution.
A mon sens, CAST n'est présent que pour le respect de la norme SQL.
Mais les auteurs du livres sont présents sur le forum, peut-être pourront-ils apporter des précisions.

[olivtone]

Merci de ton retour

Concernant le cout du CAST et du convert je l'ai lu dans le livre j'essaierai de retrouver la page de mon coté
Concernant le Test du Convert, j'ai pris une valeur toute bete dans la BDD Adventure Works 2012 et fait un CONVERT et un CAST sur la colonne indexée et celui prenait toujours l'index clustered.
Si je comprends bien c'est au cas par cas concernant la fonction TSQL sur la clause WHERE non?

Autre Question(j'en profite ) : Quelqu'un a t il un retour d'experience concernant l'activation du Lock pages in memory ?

Merci a Vous super forum

[nachid]

C'est fort possible que tu vois un Clustered Index Scan et cela ne veut pas dire que tu CAST utilise un index
Bien comprendre les SARG comme expliqué ici
http://blog.developpez.com/zinzineti...es_fonctions_q

[mikedavem]

Concernant le Test du Convert, j'ai pris une valeur toute bete dans la BDD Adventure Works 2012 et fait un CONVERT et un CAST sur la colonne indexée et celui prenait toujours l'index clustered.
Si je comprends bien c'est au cas par cas concernant la fonction TSQL sur la clause WHERE non?

Poste nous le plan d'exécution de ta requête. Comme le dit nachid, il est possible que ta requête utilise un opérateur de scan d'index qu'une recherche d'index.

Autre Question(j'en profite ) : Quelqu'un a t il un retour d'experience concernant l'activation du Lock pages in memory ?

Que veux-tu savoir sur l'activation de cette option système?

++

[olivtone]

Pour le Lock pages, j'ai vu un slide sur ce lien, pour l'optimisation de SQL sur des environnements virtualisés

http://fr.slideshare.net/DecideursIT/dat208

Il parlait sur le slide 9 des lock page in memory mais apres maintes recherche je vais abandonner cette piste d'autant plus que le serveur ne souffre

pas de pression memoire, et est en Windows 2012 server R2

pour le CONVERT et la CAST il prend bien l'index clustered et ne le scanne pas

mais cela est vraiment aleatoire en fonction des valeurs recherches

En tout cas merci de votre aide vraiment sympa

[SQLpro]

Je suis étonné de cette affirmation. En effet, un CAST est implicitement transcris en un CONVERT lors de l'élaboration du plan d’exécution.
A mon sens, CAST n'est présent que pour le respect de la norme SQL.
Mais les auteurs du livres sont présents sur le forum, peut-être pourront-ils apporter des précisions.

Et oui, aussi surprenant que cela puisse paraître, le CAST est plus rapide simplement par ce qu'il n'a pas à prendre en compte le 3e paramètre potentiel du CONVERT !

Tu peut t'amuser à reproduire le test que nous avons fait avec une table de 1253500 lignes....

A +

[olivtone]

j'ai fait le test sur 3000000 de lignes le resultat n'est pas flagrant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT TOP 3000000 *
  FROM BDD.[dbo].[toto]
  WHERE PartyObjectTypeCode = CAST ('8' AS CHAR(10))

 SQL Server \endash Temps d'exécution*: 
, Temps UC = 11547*ms, temps écoulé = 56346*ms.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 SELECT TOP 3000000 *
  FROM BDD.[dbo].[toto]
  WHERE PartyObjectTypeCode = Convert (CHAR(10), '8')

Temps UC = 10500*ms, temps écoulé = 59107*ms.

Il y a un peu plus de Gain Temps niveau CAST mais pas énorme

[aieeeuuuuu]

Avec ces requêtes, c'est tout à fait normal : le CAST ou le CONVERT ne sont éxécutés qu'une seule fois pour toutes la requête, puisque vous transtypez un littéral.

Il faut appliquer la fonction sur une colonne.

[olivtone]

desole pas compris tu as un exemple stp?

[aieeeuuuuu]

Et oui, aussi surprenant que cela puisse paraître, le CAST est plus rapide simplement par ce qu'il n'a pas à prendre en compte le 3e paramètre potentiel du CONVERT !

Comme je le disais, le CAST est implicitement transformé en CONVERT avant l'éxécution de la requête... à moins que ce comportement n'ait été modifié dans la version 2014 de SQL Server ?

[SQLpro]

Pétard les mecs, vous êtes vraiment pas bon....

1) les données :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SET NOCOUNT ON;
GO
 
CREATE TABLE T (D DATETIME)
GO
 
INSERT INTO T SELECT 1 + ABS(CHECKSUM(NEWID())) % 2958463
GO 100000

2) le test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SET STATISTICS TIME ON
GO
 
SELECT CAST(D AS DATE) FROM   T
--> SQL Server Temps d'exécution*: Temps UC = 47*ms, temps écoulé = 561*ms.
 
SELECT CONVERT(DATE, D, 0) FROM   T
--> SQL Server Temps d'exécution*: Temps UC = 62*ms, temps écoulé = 873*ms.

Vos conclusions ?

A +

[julien94320]

Vos conclusions ?

LE CAST c'est un CONVERT avec un appel en moins j'ai tout compris sissi ?!!!!

Evidement, dans ton cas il est bien plus rapide et moins gourmand en CPU mais te connaissant les chiffres doivent encore etre truqués

Merci pour l'exemple

[aieeeuuuuu]

Pétard les mecs, vous êtes vraiment pas bon....

1) les données :

2) le test :

Vos conclusions ?

Mes conclusions ?
1 - 62ms ??? il faut que tu changes de machine
2 - j'ai fait le test, et (hormis que ça prend deux fois moins de temps) je ne note pas de différence notable entre les deux, même en augmentant le nombre de lignes. Par ailleurs, j'observe toujours ceci dans le plan d’exécution, que ce soit pour la requête avec le CAST ou celle avec le CONVERT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 <ScalarOperator ScalarString="CONVERT(date,[test].[dbo].[T].[D],0)">

[olivtone]

ok je l'avais pas vu effectivement merci !!

j'attends le retour de SQLPRO pour voir les tests qu'il a fait de son coté sur les 1 million de ligne et voir vraiment la difference

merci a Tous !!!

[iberserk]

Oui il est évident que des évolutions de l'optimiseur voir même l'activation de certains trace flags pour les versions plus anciennes peuvent influencer les résultats

En clair, quelles sont vos versions.

Pour rappel, c'est un tout nouvel optimiseur en 2014...