J'ai ce scénario, il semble que MySQL prenne la plus grande valeur décimale et essaie de convertir les autres valeurs en cela.

Le problème est que cette requête est générée par une bibliothèque externe, donc je n'ai pas de contrôle sur ce code, à ce niveau au moins. Avez-vous une idée de comment résoudre ce problème?

SELECT 20 AS x
  UNION SELECT null
  UNION SELECT 2.2;
+------+
| x    |
+------+
|  9.9 | -- why from 20 to 9.9
| NULL |
|  2.2 |
+------+

résultat attendu

+------+
| x    |
+------+
|   20 | -- or 20.0, doesn't matter really in my case
| NULL |
|  2.2 |
+------+

Ajoutant plus de contexte, j'utilise Entity Framework 6 avec une bibliothèque d'extensions http://entityframework-extensions.net/ pour enregistrer les modifications par lots, en particulier la méthode context.BulkSaveChanges () ;, cette bibliothèque crée des requêtes en utilisant "select union" .

Cela ressemble à un bug pour moi et je peux confirmer ce comportement déroutant dans:

10.2.14-MariaDB

Si possible, vous pouvez convertir la valeur entière en double:

SELECT cast(20 as double) UNION SELECT null UNION SELECT 2.2;

ou assurez-vous que vous avez d'abord la valeur double:

SELECT 2.2 UNION SELECT null UNION SELECT 22;

Observations supplémentaires après lecture des commentaires dans la réponse d'Evan Carroll

select 20 union select null union select 2;
+------+
| 20   |
+------+
|   20 |
| NULL |
|    2 |
+------+

Ok, l'utilisation de valeurs int ne semble pas produire l'erreur.

select 20 union select null union select 9.0;
+------+
| 20   |
+------+
| 9.9  |
| NULL |
| 9.0  |
+------+

ERREUR: Il semble que la sortie soit décimale (2,1)

create table tmp as select * from (select 20 as x 
                                   union 
                                   select null 
                                   union 
                                   select 9.0) as t

describe tmp;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| x     | decimal(2,1) | YES  |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+

L'erreur n'est pas isolée de l'interface de ligne de commande, elle existe également pour python2-mysql-1.3.12-1.fc27.x86_64:

>>> import MySQLdb
>>> db = MySQLdb.connect(host="localhost", user="*****", passwd="*****", db="test") 
>>> cur = db.cursor()
>>> cur.execute("SELECT 20 union select null union select 2.2")
3L
>>> for row in cur.fetchall() :
...     print row
... 
(Decimal('9.9'),)
(None,)
(Decimal('2.2'),)

Curieusement, l'erreur disparaît si null est déplacé en premier ou en dernier:

select null union select 20 union select 9.0;
select 20 union select 9.0 union select null;

+------+
| NULL |
+------+
| NULL |
| 20.0 |
| 9.0  |
+------+

Si null est placé en premier, le type résultant est décimal (20,1). Si null est placé, le dernier type résultant est décimal (3,1)

L'erreur disparaît également si une autre jambe est ajoutée à l'union:

select 20 union select 6 union select null union select 9.0;
+------+
| 20   |
+------+
| 20.0 |
| 6.0  |
| NULL |
| 9.0  |
+------+

type décimal résultant (20,1)

l'ajout d'un autre null au milieu conserve l'erreur:

select 20 union select null union select null union select 9.0;
+------+
| 20   |
+------+
| 9.9  |
| NULL |
| 9.0  |
+------+

Mais l'ajout d'un null au début le corrige:

select null union select 20 union select null union select null union select 9.0;
+------+
| NULL |
+------+
| NULL |
| 20.0 |
| 9.0  |
+------+

Comme prévu, la conversion de la première valeur en décimal (3,1) fonctionne.

Enfin, la conversion explicite en décimal (2,1) produit la même erreur mais avec un avertissement:

select cast(20 as decimal(2,1));
+--------------------------+
| cast(20 as decimal(2,1)) |
+--------------------------+
| 9.9                      |
+--------------------------+
1 row in set, 1 warning (0.00 sec)

Bogue MDEV-15999

Le bogue MDEV-15999 déposé par dbdemon l'a signalé. Il a depuis été corrigé dans 10.3.1.

Nature étrange de MySQL / MariaDB

Depuis les documents,

Les noms de colonne de la première SELECTinstruction sont utilisés comme noms de colonne pour les résultats renvoyés. Les colonnes sélectionnées répertoriées dans les positions correspondantes de chaque SELECTinstruction doivent avoir le même type de données. (Par exemple, la première colonne sélectionnée par la première instruction doit avoir le même type que la première colonne sélectionnée par les autres instructions.)

Si les types de données des SELECTcolonnes correspondantes ne correspondent pas, les types et les longueurs des colonnes dans le UNIONrésultat prennent en compte les valeurs récupérées par toutes les SELECTinstructions.

Dans ce cas, ils se réconcilient decimalet integeren promouvant l'entier à un decimalqui ne peut pas le contenir. Je sais que c'est horrible, mais tout aussi horrible est ce comportement silencieux comme ça.

SELECT CAST(20 AS decimal(2,1));
+--------------------------+
| CAST(20 AS decimal(2,1)) |
+--------------------------+
|                      9.9 |
+--------------------------+

Ce qui semble ouvrir la voie à ce problème.