统一小数位数应使用ROUND()而非FORMAT()，因FORMAT()返回字符串导致排序计算错误；百分比需用100.0强制浮点运算并ROUND控制精度；四舍五入致总和偏差属正常现象，业务可接受±0.01误差。
GROUP BY结果里小数位数乱糟糟，怎么统一保留2位？
直接用 ROUND() 最稳妥，FORMAT() 在MySQL里看似方便，但实际会把数值转成字符串，后续没法参与计算或排序——比如你按「平均单价」排序时，'19.99' 和 '100.00' 会被当字符串比大小，结果错乱。
常见错误写法：SELECT FORMAT(AVG(price), 2) FROM sales GROUP BY category; —— 看起来输出整齐，但返回的是字符串，不是数值。
-
ROUND(AVG(price), 2)返回真正的 DECIMAL/DOUBLE，支持继续运算、ORDER BY、WHERE 比较 - 如果只是导出报表且确定不参与后续处理，
FORMAT()可用，但必须意识到它已脱离数值语义 - PostgreSQL 没有
FORMAT()，得用TO_CHAR(AVG(price), 'FM999999990.00')，更易出错，不如统一用ROUND()
分组后想显示「占比%」，ROUND和CAST怎么配合？
百分比本质是（本组值 / 总体汇总）× 100，但除法在SQL里容易因类型隐式转换丢精度。比如整数列相除可能截断为0。
正确做法是显式提升精度：
SELECT category, COUNT(*) AS cnt, ROUND(COUNT(*) * 100.0 / (SELECT COUNT(*) FROM sales), 2) AS pct FROM sales GROUP BY category;
- 用
100.0（带小数点）强制转为浮点运算，避免整数除法截断 -
ROUND(..., 2)控制小数位，不加这步可能输出23.456789 - 别用
CAST(COUNT(*) AS DECIMAL)冗余写法，100.0更简洁有效
MySQL中FORMAT()为什么有时多出千分位逗号，还报错？
FORMAT() 默认加千分位分隔符（如 '1,234.56'），这不是格式“美化”，而是彻底改变数据类型——返回 TEXT，且在严格模式下，若目标字段是 numeric 类型，INSERT 或 UPDATE 会直接报错：ERROR 1265 (01000): Data truncated for column 'pct' at row 1。
- 确认是否真需要逗号：报表前端或Excel完全可自行加，SQL层保持纯数字更安全
- 若非用不可，确保接收字段是
VARCHAR，且所有下游逻辑都按字符串处理 - 替代方案：用
ROUND()+ 应用层格式化，可控性高得多
分组统计+四舍五入后总和≠100%，怎么办？
这是四舍五入的固有副作用。比如三组占比分别是 33.33%、33.33%、33.34%，加起来是100.00；但若原始值是 33.333、33.333、33.333，全 ROUND(x, 2) 后变成 33.33×3=99.99。
- 业务上接受误差±0.01，通常无需处理
- 真要凑整到100%，得用「最大余额法」：先对所有项
ROUND(x, 2)，再把差额加到最大余数那组（需窗口函数+排序） - 简单场景下，改用
ROUND(x, 3)再显示时截取两位，能缓解但不根治
真正难的不是函数怎么写，而是想清楚：这个百分比是给人看的，还是给程序算的——前者可妥协，后者必须保精度。
