У мене такий сценарій, схоже, MySQL приймає найбільше десяткове значення і намагається передати інші значення цьому.

Проблема полягає в тому, що цей запит генерується зовнішньою бібліотекою, тому я не маю контролю над цим кодом, принаймні на цьому рівні. Чи маєте ви якесь уявлення, як це виправити?

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

Очікуваний результат

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

Додаючи більше контексту, я використовую Entity Framework 6 з бібліотекою розширень http://entityframework-extensions.net/ для збереження змін у партіях, зокрема методу context.BulkSaveChanges () ;, ця бібліотека створює запити, використовуючи "select union" .

Мені це здається помилкою, і я можу підтвердити цю дивовижну поведінку в:

10.2.14-MariaDB

Якщо можливо, ви можете присвоїти ціле число до подвійного:

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

або переконайтеся, що у вас є подвійне значення спочатку:

SELECT 2.2 UNION SELECT null UNION SELECT 22;

Подальші спостереження після прочитання коментарів у відповіді @Evan Carroll

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

Гаразд, використання значень int, схоже, не призводить до помилок.

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

ПОМИЛКА: Видається, що вихід є десятковим (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    |       |
+-------+--------------+------+-----+---------+-------+

Помилка не відокремлена від інтерфейсу командного рядка, вона існує і для 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'),)

Як не дивно, помилка зникає, якщо нуль переміщено першим чи останнім:

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

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

Якщо нуль ставиться першим, результат отриманий десятково (20,1). Якщо нуль розміщено, останній результат є десятковим (3,1)

Помилка також зникає, якщо до союзу додається ще одна нога:

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

отриманий тип десяткової (20,1)

додавання ще одного нуля в середині зберігає помилку:

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

Але додавання нуля на початку виправляє це:

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

Як очікується, перше значення працює в десятковий (3,1).

Нарешті, явне введення в десятковий (2,1) видає ту ж помилку, але з попередженням:

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

Баг МДЕВ-15999

Про це повідомила помилка MDEV-15999, подана dbdemon . З тих пір це було зафіксовано в 10.3.1.

Дивна природа MySQL / MariaDB

З документів,

Імена стовпців з першого SELECTтвердження використовуються як імена стовпців для повернутих результатів. Вибрані стовпці, перелічені у відповідних позиціях кожного SELECTтвердження, повинні мати однаковий тип даних. (Наприклад, перший стовпець, обраний першим оператором, повинен мати той самий тип, що і перший стовпець, обраний іншими операторами.)

Якщо типи даних відповідних SELECTстовпців не збігаються, типи та довжини стовпців у UNIONрезультаті враховують значення, отримані всіма SELECTоператорами.

У такому випадку вони узгоджуються decimalі integer, просуваючи ціле число до а, decimalяке не може містити його. Я знаю, що це жахливо, але однаково жахливо це мовчки поводиться так.

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

Що, здається, прокладає шлях цій проблемі.