MySQL里的数字函数，估计很多人都用过ROUND，可真要说清楚它在什么情况下会把2.5变成2，可能一半人都得愣一下。我在业务系统里折腾了好几年，见过不少因为“取整取错”“类型没守住精度”导致的对账事故。金额差一分钱，报表跟Excel对不上，最后查了半天，发现都是函数选型或者隐式类型转换惹的祸。
1. 从一次对账不平开始：为什么数字函数不能凭感觉用
1.1 一个让我记忆犹新的尾差事故
有一次某财务模块要按比例把订单总优惠分摊到十几个商品行，需求听起来很简单：总优惠10元，按每个商品的金额占比分下去，最后分摊之和必须等于10元。我们写好SQL之后做联调，数据怎么都对不上，每次都会差个一分钱两分钱。几个开发围着看了一个多小时，最后定位到ROUND在FLOAT字段上的表现和DECIMAL完全不一样。从那以后我给自己立了条规矩：凡是涉及金额、数量、比例的字段，一律用DECIMAL，关键计算必须显式CAST，绝不给浮点数留“差不多”的机会。
这段事故教会我的事，后来我在不少项目里都验证过：数字函数不是拿来即用的工具，每个函数都有各自的边界条件，字段类型一变，结果可能就跟着变。很多项目里埋着类似的问题，只是还没等到报表对不上的那一刻。
1.2 数据库层做计算和应用层做计算的分界线
很多人习惯把明细数据查出来，丢到Java或者Python里循环算。数据量小的时候没问题，可一旦数据量上来，循环里逐个算均值、方差、增长率，性能和代码复杂度都会很难看。数据库本身擅长集合计算，能用SQL内置函数完成的统计，尽量在SQL里完成。
比如要算每个类目的销售额月环比增长率，一条带窗口函数的SELECT就能搞定，应用层只需要接收结果集。数字函数在这里的角色，是“把原始数值变成业务口径明确的数值”。现在很多报表平台直连MySQL取数，如果SQL里的计算口径写得含糊，报表维护成本会直线上升。所以我一直觉得，理解数字函数的语义，不只是在考DBA证书时才需要，而是每个写业务SQL的人都该有的基本功。
1.3 业务里最常见的几个数字函数使用场景
如果只从出现的频率来看，数字函数最常出现在这几个地方：订单金额的折扣分摊、统计报表里的同比环比、库存余量的预警判断、用户时长的格式转换。比如“在线时长超过xx小时”要除以3600再向上取整，“库存余量低于xx时需要预警”要用比较和取整配合。这些场景单独拿出来都不复杂，但组合在一起时，选错函数就会带来一堆莫名其妙的偏差。
2. ROUND与取整家族：精确值、近似值、展示型格式的区别
这一章值得做财务和报表的同学仔细看。取整函数选择正确与否，真的直接决定账能不能对上。不夸张地说，我见过太多报表工程师在ROUND上栽跟头，问题不是函数不会用，而是没搞懂MySQL在精确值和近似值上的不同表现。
2.1 同一个ROUND，为什么DECIMAL和FLOAT不一样
先看一个例子：
SELECT ROUND(2.5, 0); -- 精确值场景下通常返回3 SELECT ROUND(CAST(2.5 AS FLOAT), 0); -- 近似值场景下可能返回2第一个结果好理解，四舍五入嘛，2.5进位到3。第二个结果在不少MySQL版本和运行环境下会返回2。原因是FLOAT存储2.5时，底层二进制表示可能是一个略小于2.5的数，ROUND判断边界时认为这个数还没到2.5，于是舍成2。官方文档里也写得很清楚：ROUND对精确值类型和近似值类型的舍入行为并不一致。很多人就是在把DECIMAL字段迁移成DOUBLE之后，发现报表里一列“x.5”的值全被舍掉了。
我经历过一次数据迁移，源库金额字段是DECIMAL(10,2)，临时表却建成了DOUBLE，迁移后对账怎么都差十几块钱。排查方式其实不复杂：先抽几行对比迁移前后的计算结果，再检查字段类型定义，一眼就能看到问题。这个教训后来变成了团队里的一个规范：金额、数量的字段类型定义好之后，不允许随意改动，除非你做好全链路回归。
2.2 TRUNCATE与ROUND：两个“舍”字的业务差别
ROUND是四舍五入，TRUNCATE是直接截断。字面上只差一个“边界值”，业务含义却完全不同。比如要对用户在线时长保留一位小数做展示，用ROUND没问题；但做活动预算分摊时，算法要求向下截断，不让三档之和超预算，这时TRUNCATE(amount * ratio, 0)就比FLOOR更直观。
TRUNCATE还有个容易被忽略的特性：它的方向是向零截断。TRUNCATE(-2.9, 0)返回-2，而FLOOR(-2.9)返回-3。如果分页、配额这类场景用了FLOOR处理负数，会意外多扣掉一部分，排查的时候很难想到是这里出了问题。我见过有人写库存扣减逻辑，用了FLOOR而不是TRUNCATE，结果负数场景下多扣了一件商品，直到客服收到用户投诉才发现。
2.3 FORMAT是展示层工具，别把它当计算函数用
FORMAT(1234567.891, 2)返回“1,234,567.89”，这是带千分位符的字符串。它的目的是给人看，不是给计算机做运算。有人图方便把FORMAT结果继续参与SUM、加减运算，MySQL虽然会做隐式转换，但字符串中的逗号会带来不少麻烦，结果可能被截断，甚至转成错误数值。
我的习惯是分两层处理：中间计算一律用DECIMAL和ROUND，最后展示的时候再包一层FORMAT。而且传给FORMAT的第一个参数必须确保是数值类型，如果你传的是字符串，隐式转换会带来额外的精度损耗。尤其在报表SQL里，FORMAT和ROUND混用会让口径变得混乱，后面维护的人根本分不清哪个数才是准的，这一点特别值得注意。
3. 向上取整、向下取整和取模：方向感与符号感
3.1 CEIL和FLOOR在负数上会反直觉
CEILING(2.1)返回3，FLOOR(2.9)返回2，这两个很容易理解。一旦参数变成负数，结果就开始跟直觉打架：CEILING(-2.1)返回-2，FLOOR(-2.9)返回-3。
原因在于CEILING的定义是“大于等于参数的最小整数”，方向是朝正无穷；FLOOR是“小于等于参数的最大整数”，方向是朝负无穷。很多人会下意识以为“向上取整”是往绝对值更大的方向取，其实完全不是。比如算库存差异，-3表示缺三件，-2.5可能处于两种口径之间，你选CEILING还是FLOOR，直接影响补货建议是“补两件”还是“补三件”。这类口径问题必须跟业务方确认清楚，不能自己拍脑袋决定，否则后面改起来又要牵扯一堆历史数据。
3.2 MOD的用途：奇偶判断、周期分桶与分批处理
MOD最常见的是判断奇偶、周期分桶，比如大表里按用户ID对10取模，把数据分成10个桶，每次只处理一个桶：
WHERE MOD(user_id, 10) = 3MOD(N, 0)返回NULL并给一个警告，这一点很多文档写得不显眼，但在SQL里连续计算时容易被忽略。还有，如果参数带小数，MOD返回的也是小数，比如MOD(10.5, 3)结果是1.5。如果你要的是整数余数，先CAST成整数再取模会更稳。我测试过很多次，凡是涉及“分桶”“分批”的逻辑，最好统一用整数类型参数，否则边界值会让整个桶的划分变得不均匀。
3.3 负数MOD的结果容易引起分桶异常
MOD(-5, 3)在MySQL里返回-2。因为MySQL的MOD遵循被除数的符号。所以如果直接拿可能为负的ID做分桶，桶号会出现负数，分组数量就不稳定。
我在统计数据分片时吃过这个亏，后来统一改成MOD(ABS(id), 10)，先取绝对值再分桶，才能保证桶号永远是0到9。如果你需要保留方向的语义，那是另一回事；但大部分业务分桶场景只关心平均切分，用ABS是更稳妥的起点。还有一个细节：MOD(ABS(id), 10)在ABS(id)特别大的时候本身没有问题，但如果id是BIGINT的最小边界，ABS可能会溢出，这种情况现实中很少见，但我在压测时遇到过，提醒一句总没错。
4. 幂运算、平方根与对数：数量级分析的工具箱
4.1 POWER和SQRT在公式类需求中的落地
POWER(2, 10)返回1024，SQRT(144)返回12。这类函数看起来偏数学，但放到业务里就是很趁手的工具。比如物流行业用距离的平方来算区域配送积分，订单系统算阶梯折扣时用基础金额乘以倍数的幂，直接用一条SQL就能完成，省掉了应用层循环。
有人会问，这些计算放到应用层不一样吗？区别在于，SQL对集合操作做了优化，一次查询直接出结果集，应用层只需接收数据，避免每行都走一次函数调用和类型转换。尤其在GROUP BY之后要按行计算结果时，SQL的写法更简洁，也更容易做单元测试。计算口径和报表工具保持一致，后续维护会少很多扯皮，这是我做了几个统计系统之后最深的感受。
4.2 LOG家族在读长尾分布时的妙用
LOG2、LOG10在分析场景里很有价值。比如内容阅读量从几百到几百万都有，直接画直方图，头部几个高阅读量内容会把图撑得很奇怪，长尾内容被压成一条线。如果对阅读量先取对数再分桶，分布会平滑很多，也能看出数量级上的规律。
SELECT LOG10(read_count) AS level, COUNT(*) FROM content_metrics WHERE read_count > 0 GROUP BY level;注意LOG的参数范围，X<=0时返回NULL并发出警告，所以取对数前最好先过滤掉非正值。另一个容易混淆的点是：LOG(X)是自然对数，LOG(B, X)才是指定底数的对数。我在代码评审里经常看到有人把LOG(10, read_count)和LOG10(read_count)混用，结果查出来的数据完全对不上，后来我养成了习惯，凡是用到LOG的地方都顺手标注一下底数。
4.3 EXP与复利、衰减模型
EXP(X)是e的X次方，常见应用包括指数衰减和连续复利。比如估算某个活动热度随时间衰减，可以用EXP(-t)做衰减因子；金融场景计算连续复利终值，也离不开EXP。EXP的增长非常快，作为中间结果时最好配合ROUND限制精度，或者提前判断输入范围，避免数值溢出变成INF。
我在写用户活跃度预测模型时，就有过输入t稍微大一点结果直接溢出的经历。后来所有进EXP的参数，都先用GREATEST和LEAST把范围卡住，再进入计算。这种方法虽然牺牲了一点精度，但能保证SQL在任何数据分布下都不会出现异常值，对线上报表来说，稳定性比极端的数学精确更重要。
5. 随机数的正确打开方式：RAND的坑与可用场景
5.1 ORDER BY RAND()在大表上是性能黑洞
随机取一条，很多人第一反应是ORDER BY RAND() LIMIT 1。数据量小的时候没问题，但表里有个几十万上百万行时，这个写法会对全表每一行生成随机数，然后整体排序，最终只取一条，成本高到离谱。我优化过一个随机推荐接口，原来就是ORDER BY RAND()，流量稍微上来，数据库CPU直接打满，问题定位过程并不复杂，执行计划一拉出来就看到了。
改成两步走之后，情况立刻好转：先用COUNT(*)拿到总行数，在应用层随机一个偏移量，再用LIMIT offset, 1去取。如果一定要纯SQL实现，也可以先算出ID范围，用FLOOR(RAND() * (max_id - min_id) + min_id)定位一个起点再LIMIT取数，但前提是ID分布均匀，有空洞时需要多试几次。我的习惯是尽量避免用ORDER BY RAND()去全表扫描，因为这是完全不必要的性能消耗，改成两步走之后，同样功能耗时能从秒级降到几十毫秒。
5.2 RAND(seed)与可重复随机
RAND()每次调用返回[0, 1)之间的随机浮点数，不带参数时每次运行结果都不同。RAND(n)带整数种子，则可以生成可重复的随机序列。这个特性在测试数据回放里特别有用：想在同一批随机数据上反复验证逻辑，或者让Demo演示每次启动都长一样，用固定种子就方便多了。
生成随机金额或随机年龄，也常常是RAND和ROUND、FLOOR配合使用。比如FLOOR(RAND() * 100)生成0到99的整数，ROUND(RAND() * 50, 2)生成两位小数的金额。这里有个很容易漏掉的点：RAND()本身不会返回1，所以如果你想要包含上限的值，表达式要处理成FLOOR(RAND() * (max - min + 1)) + min，否则上限值永远出不来。每次写这种表达式，我都会顺手在旁边注释一句取值范围，防止后来的人看走眼。
5.3 用随机数做抽样的边界意识
随机抽样在业务里经常被用来做A/B分流或审核抽样。RAND配合LIMIT可以快速拿一批随机记录，但要小心，如果分批查询同一张表，每批数据之间可能会重叠，达不到严格的抽样互斥。严格的抽样应该在上游确定好随机种子和分桶规则，或者直接生成抽样结果表，不然线上结果会越抽越偏。我见过一个运营后台的抽样功能，每次刷新都随机出一批不同的数据，运营人员误以为数据有问题，实际上就是查询语义没设计好，随机数用在错误的地方反而制造了混乱。
6. 三角函数与弧度：几何计算里绕不开的底座
6.1 弧度制是MySQL三角函数的默认单位
MySQL里SIN、COS、TAN等函数的参数一律是弧度，不是角度。有些同学习惯了角度制，直接把45传给SIN，结果跟预期完全对不上，还以为是函数坏了。其实只要用RADIANS(45)转成弧度再给三角函数，一切就正常了。反过来，用DEGREES()把弧度转回角度，方便打印和调试。
我最早写经纬度距离公式时，就吃过角度没转弧度的亏。算出来的距离比地图上显示的大了一个量级，排查了很久才发现所有三角函数参数都直接用了角度。后来我在代码注释里明确写了“角度一律先RADIANS再进入公式”，后续接手的人再也没出过这类问题。这种细节看似不起眼，但确实就是最容易浪费整个下午时间的地方。
6.2 经纬度距离计算：Haversine公式的SQL版本
LBS场景里最常见的距离公式是Haversine。地球半径取6371公里，换算成米大约是6371000米。SQL可以写成：
SELECT ROUND(6371000 * ACOS( COS(RADIANS(lat1)) * COS(RADIANS(lat2)) * COS(RADIANS(lng2) - RADIANS(lng1)) + SIN(RADIANS(lat1)) * SIN(RADIANS(lat2)) ), 0) AS distance_m FROM ...;这个公式看起来简单，但对CPU不算友好，因为每条记录都要做多次三角运算。如果表很大还硬要跑，数据库压力会很大。更好的做法是先用经纬度范围粗筛，只把候选集缩小到几公里范围内的几百条记录，再对这部分数据跑精确距离，最后在应用层排序分页。如果需求是“附近的人”这种高频查询，那已经超出普通MySQL数字函数的适用范围了，建议用专门的地理索引方案来支撑，别硬撑着全表算距离。
6.3 ATAN2：处理方向角时的替代方案
除了SIN、COS，ATAN2在几何计算里也很有用。它接收两个参数，返回从x轴正方向到点(y, x)的夹角，范围是-pi到pi。相比普通的ATAN，ATAN2能正确区分不同象限的角度，这在计算方位角、判断转向方向时非常关键。比如地图导航里算车辆朝向和目的地的夹角，直接套ATAN2就能得到-180度到180度之间的结果，避免四个象限判断的麻烦。如果你做的是LBS或者需要角度计算的业务，ATAN2值得记在脑子里。
7. 综合案例：把数字函数拼进一条真实SQL
7.1 需求背景与计算口径
最后用一个我实际写过很多次的案例，把前面提到的函数串起来：订单优惠分摊。
假设订单总金额100元，平台优惠10元，订单里有3件商品，价格分别是30、40、30。我们需要按商品价格占比把10元优惠分摊到每个商品上，保留两位小数，同时保证分摊之和严格等于10元。如果每行都直接用ROUND(10 * ratio, 2)，加起来很可能不是10元，比如三行分别是3.00、4.00、2.99，总和9.99，少了0.01。这就是尾差问题，几乎每个做订单系统的团队都会遇到。
行业里的通用处理方法是：最后一次分摊用总优惠减去前面已分摊金额的合计，保证总数一致。这个方法我们称为“最后一行兜底”，虽然听起来简单，但实际落地时怎么判断“最后一行”、怎么避免重复计算，才是真正的难点。
7.2 参考SQL和核心思路
用窗口函数可以写得很紧凑：
SELECT order_id, product_id, price, discount_ratio, CASE WHEN ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY product_id DESC) = 1 THEN ROUND(total_discount - SUM(ROUND(total_discount * discount_ratio, 2)) OVER (PARTITION BY order_id), 2) ELSE ROUND(total_discount * discount_ratio, 2) END AS allocated_discount FROM order_items;这里先给同一订单的所有商品按商品ID倒序编号，编号为1的那行被认为是兜底行，用总优惠额减去前面几行已经分摊的四舍五入结果，得到剩余金额。前面几行正常四舍五入，兜底行承担尾差，最终全单分摊金额之和一定等于总优惠额。这个写法把原本需要写存储过程或用程序循环做的逻辑，压缩成了一条查询，而且在数据量大时依然可读可控。
7.3 我在这些项目里总结的几条经验
- 金额字段一律用DECIMAL，中间计算不要随意CAST成DOUBLE或FLOAT。
- 需要精确到分的时候，比较两个计算结果前先统一ROUND到同一精度，再比较大小。
- WHERE子句里如果写ROUND(price, 2) = 8.9这样的条件，索引会失效。数字函数在条件中作用于索引列时，通常会让MySQL放弃索引，需要尽可能把函数移到常量的那一边，或者在设计表时添加冗余字段来绕开计算。
- 涉及浮点比较的对账逻辑，用ABS(a - b) < 0.0001这样的误差容忍判断，比直接用等号更安全，可以避免浮点抖动造成的假性差异。
- 分摊这类口径明确的计算，最好把规则写进SQL注释里，包括“为什么最后一行兜底”“为什么保留两位小数”，免得几个月后自己都忘了当时的设计意图。
这些经验全是我在项目里真金白银试出来的。数字函数虽然看着简单，但边界条件特别多，每一个都值得在实际场景里再验证一遍，尤其在跟钱有关的系统里。如果你也正在排查某个“怎么也差一分钱”的问题，不妨先把字段类型和ROUND行为检查一遍，很多时候答案就藏在这里。
