企业官网建设流程全解析

先问一个很基础的问题：在SQL里执行SELECT 5 / 2，你觉得结果是多少？如果按小学数学，答案是2.5。但在不少数据库里，你实际拿到的可能是2，甚至在SQL Server里直接得到3？这就是今天想聊的“除法那些事儿”。很多人在写SQL时被除法的整数截断、保留小数、四舍五入、取整方向坑过，明明逻辑没问题，报表数据就是不对，最后排查半天发现是除法的精度处理没搞对。

这篇文章会把SQL除法计算中“保留整数”和“保留几位小数”这两件事彻底讲透，包括各数据库默认行为差异、ROUND/CAST/TRUNCATE等函数的选用逻辑、开发中真正的避坑点，以及几个能直接抄走的实用写法。不管你是刚入门写SQL的新手，还是经常被报表精度折磨的取数老手，这篇都能帮你省下不少排查时间。

1. 除法结果到底是什么？先搞清楚“整数除法的默认行为”

1.1 为什么5/2在某些数据库里等于2

很多人的第一反应是“数据库是不是算错了”。其实不是算错，而是数据库对除法的默认处理规则各不相同。以MySQL为例，两个整数直接相除，结果会保留小数，SELECT 5 / 2返回2.5000；但如果你写的是SELECT 5 DIV 2，那得到的就是整数2。而在SQL Server里，SELECT 5 / 2的结果就是2，因为两个整数类型做除法时，结果会被隐式转成整数，小数点后的部分直接截断，不是四舍五入，是直接扔掉0.5。这在做统计、算平均、算占比时最容易出问题。

PostgreSQL又不一样，SELECT 5 / 2在PostgreSQL里得到的是2，但SELECT 5 / 2.0得到的是2.5000000000000000，因为它遵循的是“如果除数和被除数都是整数，结果就是整数；只要有一个是数值类型或小数类型，结果就是小数”。Oracle则比较直接，SELECT 5 / 2 FROM dual结果永远是2.5，因为它默认把整数除法当数值运算处理。所以同样的SQL语句在不同数据库里跑出不同结果，不是玄学，是类型推断规则不一样。

1.2 各数据库默认除法行为对照

我把常见数据库的默认行为整理成了下面的表，方便你对照排查问题：

这张表是排查问题的第一步。你写了一条除法SQL，先别急着调函数，先确认你所在的数据库到底走的是哪种默认规则。很多线上问题，其实在这一步就能定位。

1.3 最稳妥的做法：显式转换类型，别依赖默认行为

依赖数据库默认行为写代码，就像在流沙上盖房子，今天能跑，明天换数据库就崩。我自己的习惯是：只要涉及除法、涉及小数位，一律先把被除数或除数显式转成DECIMAL、NUMERIC或DOUBLE，宁可多打几个字符，也不猜数据库的默认规则。

-- MySQL里想得到精确的小数结果 SELECT CAST(5 AS DECIMAL(10, 4)) / 2; -- SQL Server里想得到小数结果 SELECT CAST(5 AS DECIMAL(10, 4)) / 2; -- PostgreSQL里想得到小数结果 SELECT 5::numeric / 2;

这里有个容易犯的错，很多人只转被除数不转除数，其实只要除数和被除数任意一个是小数类型，结果就是小数。所以最简单的写法是给除数加个.0，SELECT 5 / 2.0在很多数据库里就能直接拿到小数。不过，我还是建议用CAST或CONVERT显式声明精度，尤其是做金额、比例计算时，后面你会看到，精度不够会引发一系列连锁问题。

2. 保留N位小数的常用函数：ROUND、TRUNCATE、FORMAT 到底该用哪一个

2.1 ROUND不是哪里都“四舍五入”

先记住一个关键结论：ROUND的舍入规则，在不同数据库里不是完全一样的。

MySQL里的ROUND(x, d)是标准的四舍五入，ROUND(2.675, 2)理论上应该是2.68，但实际你可能得到2.67，这个问题后面会专门说。SQL Server里的ROUND(2.675, 2)结果也是2.67。为什么会这样？因为2.675这个数在计算机里存的可能是2.6749999999998，不是我们脑子里的2.675。这就是浮点数精度带来的坑。所以涉及金额计算时，不要只依赖ROUND，更要关注底层存储类型。

如果要做更严格的“四舍五入”，在SQL Server里可以配合ROUND和CAST两个函数一起用，先把结果转成DECIMAL再取位。或者干脆把数乘以100，用整数运算逻辑取整后再除以100，这样能规避不少浮点误差问题。

-- SQL Server中保留两位小数，尽量绕开浮点误差 SELECT CAST(ROUND(2.675 * 100, 0) AS INT) / 100.0;

2.2 不只是四舍五入：截断、向下取整、向上取整

保留小数不只是四舍五入一种需求。做数据清洗时，我经常碰到要“直接截断”的场景，比如金额只保留到分，多余的小数位直接丢弃，不是四舍五入。MySQL里可以用TRUNCATE(x, d)，TRUNCATE(2.678, 2)返回2.67。SQL Server没有直接对应的TRUNCATE函数，可以用ROUND的一个冷门参数：ROUND(2.678, 2, 1)，第三个参数为1时就执行截断。PostgreSQL同样可以用TRUNC(2.678, 2)实现，但注意，PostgreSQL里这个函数名是TRUNC，不是TRUNCATE。

2.3 用FORMAT做展示、用CAST做计算，别混用

FORCAT（MySQL里的FORMAT）会把数字转成带千分位分隔符的字符串，比如FORMAT(12345.678, 2)返回12,345.68。这类结果适合出报表、展示给业务看，但不适合继续参与计算，因为它是字符串。如果你在做汇总SUM、比较大小，一定要用DECIMAL或DOUBLE类型保持数值，等到最后展示的时候再用FORMAT或CONVERT转成字符串。

我见过一个开发把数据库字段设计成VARCHAR，里面存的是带千分位的金额字符串，导致SUM的时候全部变成0，排查了整整半天。所以原则很简单：入库用数值类型，计算用数值函数，展示层再考虑格式化。

3. 除法结果“保留整数”的三种姿势：向下取整、向上取整、四舍五入

3.1 FLOOR、CEILING 和 ROUND 的选型逻辑

如果你要的结果是整数，先想清楚业务需要哪种取整方式。做分页计算时用的多半是向上取整CEILING，因为总页数 = 总记录数 / 每页条数，有余数就必须多加一页。做库存扣减时可能用向下取整FLOOR，避免多扣。做统计展示时用ROUND(..., 0)四舍五入。

-- 总记录数305，每页50条，需要几页？ SELECT CEILING(305 / 50.0) AS total_pages; -- 结果7 -- 平均年龄28.7，取整数展示 SELECT ROUND(AVG(age), 0) AS avg_age FROM students; -- 结果29 -- 每人可分到多少瓶水，不能多给 SELECT FLOOR(100 / 3.0) AS bottles_per_person; -- 结果33

这三种函数在不同数据库里通用性很高，FLOOR、CEILING、ROUND基本都支持。有一点要注意：负数取整容易踩坑。FLOOR(-1.5)的结果是-2，而CEILING(-1.5)的结果是-1，很多人按“四舍五入”直觉以为是-1和-2，方向完全搞反。涉及负数的场景，一定要先拿几个边界值测一测。

3.2 百分比计算里的“整数位”陷阱

计算占比并保留整数是报表里特别常见的需求。比如统计一个班级男生占比，写法看着没问题，结果却是0%，因为没有先转浮点，整数除整数被截断了。正确写法是除以总数之前先让除数和被除数有一个变成小数类型：

-- 错误示范：结果可能是0 SELECT male_count / total_count * 100 AS percent_male FROM class_stats; -- 正确示范：先转小数再算 SELECT CAST(male_count AS DECIMAL(10, 4)) / total_count * 100 AS percent_male FROM class_stats;

这个方法比male_count * 100.0 / total_count更可控。因为乘以100.0虽然也能得到小数，但精度和取整规则还是交给数据库默认处理，遇到SQL Server时就又掉进整数截断的坑里（因为male_count * 100还是整数，整数再除整数还是截断）。先转成DECIMAL，算是跨数据库最稳妥的套路。

3.3 保留整数时，什么情况下不能用ROUND

有些场景ROUND并不合适。比如做对账、分摊、批次同步时，如果使用了四舍五入，每一行独立四舍五入后再汇总，总和可能和原始总额对不上。比如100元分给3个人，每人33.33元，3个人合计99.99元，差0.01元。这个“分账尾差”问题，做财务系统的同学应该都遇到过。解决方法通常是最后一笔采用“总额减去已分金额”，而不是每笔都直接四舍五入。也是说，先正常算前n-1笔并四舍五入，最后一笔用总金额减去前面n-1笔之和，保证总额一分不差。

4. 实操过程：几个我写SQL除法的真实场景记录

4.1 场景一：统计学生平均年龄时被整数除法坑了

有一次帮一个老师做班级统计，表里的学生年龄字段是整数类型，需求是算出平均年龄。我一开始写的是：

SELECT AVG(age) FROM students;

查出来平均年龄28.7，老师说要整数展示，我改成：

SELECT ROUND(AVG(age), 0) AS avg_age FROM students;

看似顺理成章，结果报表里显示的“平均年龄29”是没有问题的。但我注意到，如果直接对两个整数做平均而不是用AVG聚合，就会出问题。比如想算的是男生平均年龄和女生平均年龄的差值，我写成：

SELECT (SUM(male_age) / COUNT(male_id)) - (SUM(female_age) / COUNT(female_id)) AS age_diff FROM stats;

在SQL Server环境下，SUM(male_age) / COUNT(male_id)两边都是整数，结果直接截断成整数，差值算出来差了1岁甚至更多。排查才发现问题出在除法上，不是数据错。后来统一改成先转DECIMAL再运算，结果就准了。从那以后，我只要写除法就会条件反射式地加CAST，哪怕是AVG聚合函数内部可以处理，也会在外层再做一层精度控制。

4.2 场景二：金额比例分摊后，最后一分钱去哪了

再讲一个经典的分摊场景。系统要给一批订单按比例分摊优惠券金额，订单金额分别是100、200、300，优惠券总额是60元，按比例分摊到每个订单。如果每个订单都按订单金额 / 600 * 60计算并保留两位小数，会出现什么？3个订单的计算结果可能是10.00、20.00、30.00，加起来正好60。但假如订单金额换成101、202、297，逐个四舍五入后，累计金额经常不等于60。

这种场景我的处理套路是：前面几条订单正常计算并用ROUND保留两位，最后一条订单直接等于总优惠金额减去已分摊金额，保证合计分毫不差。同时，比例系数用CAST(amount AS DECIMAL(18, 6))，中间过程保留6位小数，最后再统一四舍五入到2位，能显著降低累计误差。

-- 订单明细表：amount是订单金额，ratio是分摊系数 UPDATE order_detail SET discount = CASE WHEN id = (SELECT MAX(id) FROM order_detail) THEN total_discount - SUM(discount) OVER (ORDER BY id ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) ELSE CAST(amount AS DECIMAL(18, 6)) / total_amount * total_discount END;

这段SQL里的窗口函数只是用来说明“最后一条订单特殊对待”，实际业务里可能用行号或主键排序来实现。核心思想是：不要把四舍五入放在每一步，先把精度带够，最后一步再收敛。

4.3 场景三：SQL去重时，除法精度导致了两条“不同”的重复记录

有一次在清洗数据时，我用ROW_NUMBER()按某个唯一键去重，发现同一个订单号出现了两遍。后来排查了半天，发现源头不是去重逻辑，而是生成唯一键时用到了除法计算比值，由于精度设置不一样，同样逻辑下一条记录是0.33，另一条是0.3300，导致字符串拼接出来的唯一键不同。

这类问题其实提醒我们：凡是参与唯一键、JOIN关联、分组条件的除法结果，一定要先统一精度。比如统一CAST(x / y AS DECIMAL(10, 2))再拼接，否则就会出现“数据看起来一样，关联就是关联不上”的灵异事件。

5. 常见问题排查与避坑清单，附实用小工具写法

5.1 一张表看懂：同一条SQL在不同数据库的结果差异

这个表可以当作参考。它背后的核心逻辑就一句话：除法结果的精度，取决于参与运算的最高精度类型，而整型默认属于最低精度级别。

5.2 排查除法问题的五个步骤

我的排查顺序一般是：

1. 先确认数据库类型，查一下这种数据库对整数除法的默认处理规则。
2. 再确认字段类型，看参与运算的是不是INT、BIGINT、SMALLINT等整数类型。
3. 然后确认函数行为，ROUND、TRUNCATE、CAST、CONVERT在不同数据库里的语法和语义是否一致。
4. 接着验证边界条件，包括除数为0、负数、NULL、极小值、极大值的情况。
5. 最后对照业务预期，确认是“直接截断”“四舍五入”还是“向上取整”，再调整函数。

5.3 几个必须记住的避坑细节

注意：任何数据库里，除数为0都会报错或返回NULL，撰写SQL时务必用NULLIF(除数, 0)包一层，或者加CASE WHEN条件判断，避免线上报表突然报错。

-- 防除零的两种常用写法 SELECT total / NULLIF(count, 0) AS avg_value FROM stats; SELECT CASE WHEN count = 0 THEN 0 ELSE total / count END AS avg_value FROM stats;

另一个容易被忽视的问题：用ROUND保留小数位的时候，如果第一个参数本身就是DECIMAL，精度也可能被扩大到意想不到的位数。比如CAST(2.675 AS DECIMAL(10, 3))先取值，再做ROUND(..., 2)，跟直接对2.675做ROUND结果可能不同。遇到精确计算需求时，先把参数的精度想清楚，再决定加不加CAST。

5.4 后续可以试着做的一个小练习

要彻底把这些知识用熟，建议拿一张真实的业务表做三个小需求：一是统计某个指标的保留两位小数占比；二是统计分页需要的向上取整页数；三是对一个金额字段做比例分摊且保证总数一致。每个需求都分别用MySQL、SQL Server或PostgreSQL跑一遍，你会发现同一套SQL在不同数据库需要调整的细节比想象中多。能把这些差异梳理清楚，再遇到“除法结果不对”的问题，基本上心里就有底了。

我个人在写SQL时还有个习惯：所有除法线上改动前，先复制一条真实数据跑一遍计算结果，肉眼核对完再更新正式代码。除法看着简单，但它引发的精度问题往往藏在数据量和边界值里，不是看几行逻辑就能发现的。希望你读完这篇能少踩几个坑，写出更稳的SQL。