Discussion :

[J1]

Bonjour,

je constate quelque chose de particulièrement étrange sous SQL Server 2012 (Express Edition).

Soit un serveur lié MySQL nommé linked1.
Ce serveur expose une table t1 de quelques centaines de milliers de lignes, avec une colonne f1 de type DECIMAL(10,0) NOT NULL et contenant des valeurs que nous considèrerons sans importance.

Si j'exécute la requête suivante sous SQL Server (c'est un cas d'école pour mettre en évidence ma problématique)...

Code :

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

1
2
SELECT 1 FROM OPENQUERY(linked1, 'SELECT f1 FROM t1')
WHERE f1=12;

... j'ai un temps de réponse de 19 secondes.

Si j'exécute la requête suivante...

Code :

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

1
2
SELECT 1 FROM OPENQUERY(linked1, 'SELECT CAST(f1 AS CHAR(20)) as f1b FROM t1')
WHERE f1b='12';

... j'ai un temps de réponse de 8 secondes.

J'avoue que ça va à l'encontre de ce que je sais des bases de données.
Dans la deuxième requête, non seulement je perds du temps (de traitement) à transtyper ma colonne sous MySQL mais c'est en plus pour forcer SQL Server à faire une recherche sur une colonne de type caractère plutôt que numérique.
Et le tout va au final deux fois plus vite que la requête initiale !
Si je n'en avais pas fait l'expérience, j'avoue que je ne l'aurais pas cru, tant ça me semble contre-intuitif.

Voyez-vous une explication ? SQL Server traiterait-il d'une manière particulière les données "rapatriées" d'un serveur lié, de telle sorte qu'une colonne de type caractère renvoyée par MySQL permettrait en effet d'améliorer les performances côté SQL Server ?

Merci d'avance pour vos lumières.

[SQLpro]

MySQL utilise des types de données spécifique qui n'existe pas en SQL.
Par exemple les entiers signés et dimensionné n'existe pas dans le langage SQL.
Or MySQL qui est un des plus mauvais SGBDR a utilisé ce genre de bidouilles parce que leurs concepteurs étaient incapable de mettre des contraintes de domaines CHECK !
De ce fait, et même dans ODBC qui est assez normatif, ces types de données ne sont pas correctement reconnu et de ce fait MySQL doit faire des conversion à la volée dans les flux de données (vive MySQmerde !!!).
En forçant le typage, vous soulagez ODBC qui opère alors plus naturellement.

Bref, évitez d'utiliser cette abomination qui s’appelle MySQL !

A +

[J1]

Bonjour SQLpro et merci pour votre réponse.

Même si je ne partage pas votre opinion sur MySQL, l'éventualité d'un type de données MySQL un peu trop exotique (et donc difficile à traiter par SQL Server) m'avait en effet traversé l'esprit. Mais là, nous sommes sur un type MySQL DECIMAL, qui a un équivalent exact côté SQL Server : le type NUMERIC.
D'ailleurs, lorsque je ne transtype pas ma colonne DECIMAL(10,0) en CHAR(20) dans ma requête MySQL et que je crée une vue SQL Server basée sur cette requête (via un OPENQUERY), ma vue SQL Server expose bien un type NUMERIC(10,0).
Bref, nous sommes face à deux SGBD disposant de deux types de données a priori parfaitement compatibles.

Reste la possibilité que le flux ODBC transtype implicitement le DECIMAL de MySQL vers un type intermédiaire avant que celui-ci soit à nouveau transtypé vers le NUMERIC de SQL Server. Ce serait l'hypothèse que vous privilégieriez pour expliquer les performances que je constate ?

[SQLpro]

Bref, nous sommes face à deux SGBD disposant de deux types de données a priori parfaitement compatibles.

Seul le nom est identique !

Non, l'implémentation du type DECIMAL de MySQL lui est propre et dévie de la norme sur de nombeux points :
extrait de la doc : https://dev.mysql.com/doc/refman/5.0...teristics.html
"
The SQL standard requires that the precision of NUMERIC(M,D) be exactly M digits. For DECIMAL(M,D), the standard requires a precision of at least M digits but permits more. In MySQL, DECIMAL(M,D) and NUMERIC(M,D) are the same, and both have a precision of exactly M digits.
"

Voir aussi les "Summary of incompatibilities: " qui explique que bien que vous indiquiez DECIMAL celui ci peut ne pas être conforme en fonction de la version de la table

Bref comme à l'habitude de ce SGDB non relationnel furieusement mal branlé, un merdier sans nom !

A +

[J1]

Up.

Désolé de ne pas avoir répondu plus tôt mais je voulais avant cela faire un test, que je viens seulement de trouver le temps de faire.

Pour valider votre hypothèse, je viens en effet d'exécuter les mêmes requêtes, mais avec une colonne f2 de type INTEGER (et non plus DECIMAL) sous MySQL.

Code :

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

1
2
SELECT 1 FROM OPENQUERY(linked1, 'SELECT f2 FROM t1')
WHERE f2=12;

Temps de réponse de 9 secondes.

Code :

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

1
2
SELECT 1 FROM OPENQUERY(linked1, 'SELECT CAST(f2 AS CHAR(20)) as f2b FROM t1')
WHERE f2b='12';

Temps de réponse de 9 secondes (c'était 8 secondes lors de mon test initial il y a 3 semaines mais c'est une question de charge du serveur).

Avec une colonne f2 de type INTEGER sous MySQL, les temps de réponse sont donc identiques, avec ou sans le CAST.
L'écart de performances que je constatais initialement en CASTant / ne CASTant pas ma colonne DECIMAL en CHAR pourrait donc tout à fait être lié à la spécificité du type de données DECIMAL sous MySQL, comme vous l'évoquiez.

Merci donc pour vos lumières, SQLpro ! Je considère la question résolue.

Bonne fin de journée.

[SQLpro]

Encore un bug de MySQL lié à son aspect non conforme à la norme !!!!!

A +