MySQL中MOD()和%完全等价，均遵循被除数符号决定结果符号的规则，如MOD(-7,3)返回-1；需非负余数时应使用(a % b + b) % b。
MySQL里MOD()和%到底有没有区别
没有本质区别，MOD(a, b)就是a % b的函数写法，两者在MySQL中完全等价，生成相同执行计划，性能无差异。但注意：它们都遵循“被除数符号决定结果符号”的规则，不是数学意义上的非负余数。
常见错误现象：SELECT MOD(-7, 3); 返回 -1，而不是 2；有人误以为这是bug，其实是设计如此——和Python的%行为不同。
- 如果业务需要非负余数（比如分页偏移、哈希取桶），得手动校正：
(a % b + b) % b -
MOD()在SQL标准中更可移植，但%写起来快，日常用哪个都行 - 当
b为0时，两者都报错：ERROR 1365 (22012): Division by zero
PostgreSQL不支持MOD()函数？其实是语法细节问题
PostgreSQL确实有MOD()函数，但它**只接受整数参数**，传入float或numeric会直接报错：ERROR: function mod(double precision, integer) does not exist。
使用场景：你从MySQL迁SQL过来，原句MOD(price * 100, 10)在PostgreSQL里崩了——因为price是numeric，乘完还是numeric。
- 解决办法：显式转整型，如
MOD(CAST(price * 100 AS bigint), 10) - 更稳妥的做法是改用
%运算符，它对numeric类型原生支持：(price * 100) % 10 - 注意：
%在PostgreSQL里不能用于浮点数（float4/float8），只支持integer和numeric
SQLite里%能用，但MOD()根本不存在
SQLite没有MOD()函数，只有%运算符，且它只对整数生效。如果你传入小数，SQLite会先截断成整数再算——不报错，但结果易误导。
常见错误现象：SELECT 7.9 % 3; 返回 1（因为7.9被隐式转成7），而你以为它会做浮点模运算。
- 要处理小数取余，必须自己模拟：比如用
7.9 - CAST(7.9 / 3 AS INTEGER) * 3 - 别依赖隐式转换，显式用
CAST(x AS INTEGER)表明意图 - SQLite的
%不支持负数左操作数的可预测行为（不同版本可能略有差异），尽量避免-7 % 3这类写法
跨数据库写安全取余表达式的关键点
真正麻烦的不是语法，而是“余数定义不一致”：MySQL/PostgreSQL按被除数符号定结果，SQL Server也一样；但Oracle的MOD()其实返回的是a - b * FLOOR(a/b)，对负数结果不同。
如果你的SQL要跑在多个库上，又涉及负值输入，别幻想一个表达式通吃。
- 最稳方案：统一用
(a % b + b) % b（前提是所有目标库都支持%且b>0） - PostgreSQL和SQLite需确保a、b都是整型；MySQL会自动转，但隐式转换可能掩盖精度问题
- 遇到
NULL参与运算时，所有库都返回NULL，这点倒是一致
实际项目里，边界情况比语法更耗时间——特别是当字段来自用户输入或外部API，符号和类型都不可控的时候。
