Ho questo scenario, sembra che MySQL stia prendendo il valore decimale più grande e cerca di trasmettere gli altri valori a quello.

Il problema è che questa query è generata da una libreria esterna, quindi non ho il controllo su questo codice, almeno a questo livello. Hai idea di come risolvere questo problema?

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

Risultato atteso

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

Aggiungendo più contesto, sto usando Entity Framework 6 con una libreria di estensioni http://entityframework-extensions.net/ per salvare le modifiche in batch, in particolare il metodo context.BulkSaveChanges (); questa libreria crea query usando "seleziona unione" .

Mi sembra un bug e posso confermare questo comportamento sconcertante in:

10.2.14-MariaDB

Se possibile, puoi trasmettere il valore intero in un doppio:

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

o assicurati di avere prima il doppio valore:

SELECT 2.2 UNION SELECT null UNION SELECT 22;

Ulteriori osservazioni dopo aver letto i commenti nella risposta di @Evan Carroll

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

Ok, l'utilizzo di valori int non sembra produrre l'errore.

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

ERRORE: sembra che l'output sia decimale (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'errore non è isolato nell'interfaccia della riga di comando, esiste anche per 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'),)

Stranamente, l'errore scompare se il valore null viene spostato per primo o per ultimo:

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

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

Se il valore null viene inserito per primo, il tipo risultante è decimale (20,1). Se viene inserito null l'ultimo tipo risultante è decimale (3,1)

L'errore scompare anche se viene aggiunta un'altra gamba all'unione:

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

risultante tipo decimale (20,1)

l'aggiunta di un altro null al centro preserva l'errore:

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

Ma l'aggiunta di un null all'inizio lo risolve:

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

Come previsto, il casting del primo valore in decimale (3,1) funziona.

Infine, il cast esplicito in decimale (2,1) produce lo stesso errore ma con un avviso:

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

Bug MDEV-15999

Bug MDEV-15999 presentato da dbdemon segnalato questo. Da allora è stato risolto in 10.3.1.

Strana natura MySQL / MariaDB

Dai documenti,

I nomi di colonna della prima SELECTistruzione vengono utilizzati come nomi di colonna per i risultati restituiti. Le colonne selezionate elencate nelle posizioni corrispondenti di ciascuna SELECTistruzione devono avere lo stesso tipo di dati. (Ad esempio, la prima colonna selezionata dalla prima istruzione dovrebbe avere lo stesso tipo della prima colonna selezionata dalle altre istruzioni.)

Se i tipi di dati delle SELECTcolonne corrispondenti non corrispondono, i tipi e le lunghezze delle colonne nel UNIONrisultato tengono conto dei valori recuperati da tutte le SELECTistruzioni.

In questo caso, si riconciliano decimale integerpromuovendo il numero intero in un decimalche non può contenerlo. So che è orribile, ma altrettanto orribile è che si comporta in silenzio in quel modo.

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

Il che sembra aprire la strada a questo problema.