mysql的mod函数结果符号与被除数一致，如mod(-7,3)返回-1；需用(a % b + b) % b或if(a
MOD函数返回值为什么是负数？
MySQL的MOD函数在被除数为负时，结果符号跟随被除数，不是简单取绝对值余数。比如MOD(-7, 3)返回-1，而非2——这和多数编程语言（如Python的%）行为不一致，容易在数据分片、分页计算中出错。
- 真正想得到非负余数，用
(a % b + b) % b或IF(a - 如果只是判断奇偶，
MOD(col, 2) = 0仍可靠；但用于分桶（如MOD(id, 4)做路由）时，负ID会导致桶号为-1、-2等非法值 -
MOD对NULL输入返回NULL，不做隐式转换，注意上游字段是否可能为空
MOD和%运算符有区别吗？
没有实质区别。MOD(a,b)和a % b完全等价，都是调用同一内部函数，性能、精度、NULL处理行为一致。官方文档也明确说明二者可互换。
- 写法偏好上：
%更紧凑，适合表达式密集场景（如SELECT id % 10 AS bucket）；MOD()更显式，便于SQL审查或团队规范统一 - 注意：在存储过程或触发器里混用时，别因括号风格不一致引发可读性问题，比如
MOD(id, 5) + 1比id % 5 + 1多一层括号，但计算优先级相同 - 两者都不支持浮点数精确取模——
MOD(3.14, 1)会先将3.14转为DECIMAL再算，结果是0.14，但精度取决于列定义，不是IEEE 754意义上的“余数”
用MOD做分表/分库路由时踩过哪些坑？
直接拿MOD(id, N)当分片键，上线后才发现数据倾斜或扩容困难，核心问题是没考虑业务增长和变更成本。
- ID如果是自增整型，初期看起来均匀，但一旦用
REPLACE INTO或批量导入跳号，MOD结果就不再稳定——同一个ID反复插入可能落到不同分片 - 扩容从4库扩到8库时，
MOD(id, 4)→MOD(id, 8)几乎全部重分布，无法平滑迁移；应提前用一致性哈希或CONV(MD5(id), 16, 10) % N类方案 - 若用字符串主键（如UUID），不能直接
MOD(uuid_col, N)——会报错Invalid argument for function mod，必须先转成数字，例如MOD(CONV(LEFT(REPLACE(uuid_col, '-', ''), 12), 16, 10), N)
MOD能替代WHERE条件中的范围过滤吗？
不能。有人试图用MOD(created_at, 86400) = 3600来查“每天上午1点的数据”，这是典型误用——created_at是时间戳（如1717023600），对它取模毫无业务意义。
-
MOD只适合离散整型字段的等值分组，比如用户ID、订单号、批次编号 - 时间类过滤必须用
HOUR()、DAYOFWEEK()或UNIX_TIMESTAMP()转换后再计算，例如HOUR(FROM_UNIXTIME(created_at)) = 1 - 在WHERE中滥用
MOD还可能导致索引失效——即使id有索引，MOD(id, 100) = 5也无法走索引，因为MySQL无法预判哪些id满足该条件
MOD前，先确认字段类型是否为整型、值域是否稳定、业务逻辑是否真的需要“循环映射”。最常被忽略的是：负值处理和索引失效这两条，一错就难排查。
