Не могу изменить поле таблицы с плавающего на десятичное в mysql-workbench

Question

Я создал таблицу со столбцом типа FLOAT.Однако я обнаружил, что когда я запрашиваю значения MAX, MIN, AVG столбца, я получаю неточные числа, где возвращаемое значение больше, чем то, что фактически хранится в таблице.Например, это фактическое максимальное число в таблице: 0,00348675.Почему-то MAX возвращает это: 0,0034867459908127785

Неточность оказалась связана с выбором FLOAT в качестве типа.По этой причине я хочу изменить тип столбцов на DECIMAL.

Я использую mysql-workbench в Ubuntu 18. Когда я щелкаю правой кнопкой мыши по таблице и выбираю Alter Table, я могу изменить типы данных.К сожалению, когда я изменяю соответствующее поле с FLOAT на DECIMAL, FLOAT автоматически возвращается снова.Верстак не может выбрать DECIMAL по какой-то причине.Смотрите эту картинку.Я могу выбрать DECIMAL из списка.Затем, когда я перемещаю мышь в другое место, чтобы щелкнуть по следующей пустой строке, чтобы я мог нажать Apply, DECIMAL исчезнет и FLOAT снова вернется:

Может кто-нибудь посоветовать мне, в чем причина проблемы?как преодолеть проблему?

Answer 1

FLOAT и DOUBLE кодируются в двоичном, а не в десятичном виде.Следовательно, большинство дробных чисел не может быть представлено точно при хранении.(Числа, заканчивающиеся на .5, .25, .75, .125 и т. Д.) Могут быть сохранены именно потому, что они включают степени 2.

FLOAT хорошо до о 7 значимыхцифры;DOUBLE до 16.

0.00348675              You stored this decimal
0.003486746000000096    After conversion to binary, then back to decimal
0.0034867459908127785   See below

(Я подозреваю, что вы на самом деле сохранили 0.003486756.)

Некоторые вычисления выполняются в DOUBLE;Я подозреваю, что MAX() делает такое.Это включало преобразование FLOAT в DOUBLE.Ничего не потеряно в этом преобразовании .

ОК, я не могу закончить объяснение.

Достаточно сказать - всякий раз, когда используется FLOAT или DOUBLE, имейте в виду, что арифметика и отображение имеют такие причуды.

В некоторых случаях MySQL пытается избежать таких проблем, используя DECIMAL.Я бы предположил , что это как-то здесь задействовано, потому что среднее число выше имеет около 14 значащих цифр , а не 16, подразумевая, что задействовано что-то отличное от DOUBLE - возможно DECIMAL(..., 16).Примечание: это десятичных знаков , в отличие от значимых цифр _.

Если вы хотите продолжить это, предоставьте короткий тестовый пример в сообщении об ошибке вhttp://bugs.mysql.com и опубликуйте подобное здесь.