SQL中的取模运算看似简单，但不同数据库实现细节差异不小，稍不留神就可能踩坑。先说个最直观的对比：MySQL里MOD(a, b)和a % b完全等价，当b为0时温柔地返回NULL；而PostgreSQL的MOD(a, b)在b=0时直接报错division by zero，毫不留情。如果你需要写跨数据库兼容的SQL，建议优先使用%操作符（MySQL和PostgreSQL都支持），并显式加上WHERE b != 0判断，这样至少能避免运行时崩溃。

MOD函数在MySQL和PostgreSQL中的行为差异

MySQL和PostgreSQL虽然都支持MOD()函数，但参数顺序和NULL处理逻辑存在明显差异。MySQL中MOD(a, b)等价于a % b，当b为0时返回NULL，不会中断执行；PostgreSQL的MOD(a, b)则在b = 0时直接抛出division by zero错误。如果需要在两个数据库之间复用SQL，最稳妥的方式是使用%操作符（二者均支持），并显式增加WHERE b != 0条件来提前过滤。

Oracle和SQL Server不支持MOD()函数

Oracle用MOD(a, b)函数，但SQL Server根本不认识MOD()——只认%操作符。在SQL Server里写MOD(10, 3)，会收到Invalid column name 'MOD'的错误提示。正确写法是10 % 3。还有一点必须注意：SQL Server中负数取模结果符号跟随被除数，例如-7 % 3 = -1；而MySQL和PostgreSQL中符号跟随除数，-7 % 3 = 2。这个差异在跨数据库迁移时很容易引发隐蔽的逻辑错误。

用MOD实现分页偏移量校验

一个常见需求：限制OFFSET必须是每页大小的整数倍，防止前端传错值导致数据错位。比如每页10条，允许的offset只能是0、10、20……可以用MOD()做校验：

SELECT * FROM orders WHERE MOD(:offset, 10) = 0 LIMIT 10 OFFSET :offset;

实际执行前应先检查MOD(:offset, 10)是否为0，否则跳过查询或直接报错。注意:offset需为非负整数，且MOD(-5, 10)在不同数据库结果不一致，务必提前过滤负值。

MOD与负数、浮点数配合时的陷阱

MOD()对浮点数的支持并不稳定：MySQL允许MOD(5.7, 2.1)，但结果精度不可靠；PostgreSQL要求两参数均为整数类型，否则报错function mod(double precision, double precision) does not exist。负数场景更要小心：

• MOD(-8, 3)在MySQL返回1，在PostgreSQL也返回1，但在SQL Server用%返回-2
• 想统一行为，建议先用ABS()转正再取模，再根据原始符号修正结果
• 涉及金额或ID类字段时，避免对浮点列直接取模，先CAST(x AS BIGINT)再运算