svnvladсокращается при банковском округлении, когда 5 с четными сотыми округляется в меньшую сторону, с нечетными - в большую.Это ложь. Та самая, которая статистика.

svnvladМожно ли как-то это сделать с помощью MySQL?Для начала - какой именно тип округляемого значения? Ибо, согласно мануалу:
https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_round For exact-value numbers, ROUND() uses the “round half away from zero” or “round toward nearest” rule: A value with a fractional part of .5 or greater is rounded up to the next integer if positive or down to the next integer if negative. (In other words, it is rounded away from zero.) A value with a fractional part less than .5 is rounded down to the next integer if positive or up to the next integer if negative.

For approximate-value numbers, the result depends on the C library. On many systems, this means that ROUND() uses the "round to nearest even" rule: A value with any fractional part is rounded to the nearest even integer.

svnvladSELECT ROUND(0.025, 2), ROUND (0.035, 2) выдает результат 0.03 и 0.04 соответственно.


svnvladт.е. на одних системах ROUND работает как обычно, на других как банковское? Почему такой произвол? Должно же быть единообразие.Расскажи это тем, кто пишет используемые при компиляции библиотеки функций.

svnvladокругляемые поля типа DECIMAL(11,5) То есть, в классификации документации, точные (exact-value numbers) - поэтому округление выполняется по арифметическим правилам.
К сожалению, CAST/CONVERT не имеют типа приведения к FLOAT/DOUBLE типу.
Всё, что можно предложить - это изменение типа поля на DOUBLE.

Можно, пиши... типа MyRound(val) = Round(val/2)*2

Кстати, эта же формула объясняет, почему утверждения о бОльшей точности расчётов при булгахтерском округлении есть голимый бред.

Ну вообще-то DECIMAL и NUMERIC - это в понятиях MySQL синонимы.