MySQL, используя десятичный тип, все еще получает неточный вывод при использовании математических функций

Иметь PHP-скрипт, использующий все правильные функции bcmath, и полностью понимать проблемы с плавающей точкой. Я также использую десятичные столбцы, потому что, как мне показалось, они хранятся в другом типе, и математика лучше для них.

Итак, у меня есть запрос:
INSERT INTO mytable (идентификатор, количество) ЗНАЧЕНИЯ (‘идентификатор’, ‘some_number’) ON DUPLICATE KEY UPDATE amount = amount + some_number;

В основном — если у нас нет строки, вставьте ее, а если у нас есть, добавьте some_number.

Столбец some_number является десятичным (24,8)

Когда выполняется это с some_number равным 72100312.72872099 и текущая строка обнуляется на 0,00000000, математика заканчивается с колонкой 72100312.72872100.

Если some_number 72100312.72872098, он работает нормально. Если это 72100312.72872101, то это хорошо. Если я делаю 11111111.72872099, это нормально.

Если текущая строка не равна нулю, а вместо этого .00000005, то 72100312.72872099 добавляет штраф, и итоговое значение равно 72100312.72872104, как и ожидалось.

Это как будто ты испортил математику. И я думал, что десятичные столбцы невосприимчивы к этому.

Есть ли способ исправить это или сделать обновление лучше? Я ДЕЙСТВИТЕЛЬНО предпочел бы не делать выбор, bcadd, а затем обновление. Этот тип строки (вставка при двойном обновлении) появляется в коде около 120 раз. Это много ретро-настройки для выбора / bcadd / update.

Приложение: Просто прочитайте серверы MySQL до версии 5.0, преобразованной в числа с плавающей точкой для математики. Я на 5,5. Это не < 5.0 выпуск.

Edit2: версия клиента mysqlnd 5.0.11 — не уверены, что это может быть частью проблемы? Сервер должен делать математику, правда, правильно?