Eu tenho esse cenário, parece que o MySQL está usando o maior valor decimal e tenta converter os outros valores para isso.

O problema é que essa consulta é gerada por uma biblioteca externa, portanto, não tenho controle sobre esse código, pelo menos nesse nível. Você tem alguma idéia de como consertar isso?

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

resultado esperado

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

Adicionando mais contexto, estou usando o Entity Framework 6 com uma biblioteca de extensões http://entityframework-extensions.net/ para salvar alterações em lotes, especificamente o método context.BulkSaveChanges () ;, essa biblioteca cria consultas usando "select union" .

Parece um bug para mim e posso confirmar esse comportamento intrigante em:

10.2.14-MariaDB

Se possível, você pode converter o valor inteiro em um dobro:

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

ou verifique se você tem o valor duplo primeiro:

SELECT 2.2 UNION SELECT null UNION SELECT 22;

Outras observações depois de ler os comentários na resposta de @Evan Carroll

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

Ok, o uso de valores int parece não produzir o erro.

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

ERRO: Parece que a saída é decimal (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    |       |
+-------+--------------+------+-----+---------+-------+

O erro não está isolado na interface da linha de comandos, existe também para 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'),)

Curiosamente, o erro desaparece se o nulo for movido primeiro ou por último:

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 null for colocado em primeiro lugar, o tipo resultante será decimal (20,1). Se nulo for colocado, o último tipo resultante será decimal (3,1)

O erro também desaparece se outra perna for adicionada à união:

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

tipo resultante decimal (20,1)

adicionar outro nulo no meio preserva o erro:

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

Mas adicionar um nulo no começo o corrige:

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

Como esperado, o lançamento do primeiro valor para decimal (3,1) funciona.

Por fim, converter explicitamente para decimal (2,1) produz o mesmo erro, mas com um aviso:

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

O bug MDEV-15999 registrado por dbdemon relatou isso. Desde então, foi corrigido no 10.3.1.

Natureza estranha do MySQL / MariaDB

Dos documentos,

Os nomes das colunas da primeira SELECTinstrução são usados ​​como os nomes das colunas para os resultados retornados. As colunas selecionadas listadas nas posições correspondentes de cada SELECTinstrução devem ter o mesmo tipo de dados. (Por exemplo, a primeira coluna selecionada pela primeira instrução deve ter o mesmo tipo que a primeira coluna selecionada pelas outras instruções.)

Se os tipos de dados das SELECTcolunas correspondentes não corresponderem, os tipos e comprimentos das colunas no UNIONresultado levarão em conta os valores recuperados por todas as SELECTinstruções.

Nesse caso, eles se reconciliam decimale integerpromovendo o número inteiro para um decimalque não pode contê-lo. Eu sei que isso é horrível, mas igualmente horrível é esse comportamento silencioso assim.

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

O que parece abrir o caminho para esse problema.