mod运算符在where子句中应写为mod(id, 2) = 1，但仅mysql/mariadb原生支持；postgresql、sql server、oracle、sqlite等主流数据库不识别mod()函数，须用%运算符，且负数处理与索引失效需特别注意。
MOD 运算符在 WHERE 子句中怎么写才有效
直接用 MOD(id, 2) = 1 是最稳妥的方式，适用于 MySQL、PostgreSQL、Oracle 和 SQL Server（2005+）。注意别写成 id % 2 = 1 ——虽然多数数据库也支持 %，但 MOD() 是 SQL 标准函数，可移植性更强；而且某些场景下（比如负数 ID），% 的行为因数据库而异，MOD() 更一致。
常见错误是漏掉括号或参数顺序写反：MOD(2, id) 是错的，第一个参数必须是被除数（即字段），第二个是除数。
负数 ID 会导致 MOD 判断失效吗
会，但只在部分数据库里出问题。MySQL 的 MOD(-3, 2) 返回 -1，所以 MOD(id, 2) = 1 会漏掉负奇数；PostgreSQL 和 Oracle 的 MOD() 总返回非负余数，MOD(-3, 2) 是 1，判断正常。
如果表里可能有负 ID（比如同步系统生成的 ID），更安全的写法是：
WHERE ABS(id) % 2 = 1
或者统一用：
-
WHERE id % 2 != 0（兼容大多数引擎，且对负数也成立） - 避免依赖
MOD()的符号行为，直接判断“不等于 0”更直观
性能上 MOD 条件能走索引吗
不能。无论写成 MOD(id, 2) = 1 还是 id % 2 = 1，数据库都无法利用 id 字段的 B-tree 索引，因为这是对列做了计算，索引值不匹配表达式结果。
如果查询量大且频繁按奇偶筛选，考虑以下替代方案：
- 加一个持久化计算列，如
is_odd AS (CASE WHEN id % 2 = 1 THEN 1 ELSE 0 END) STORED，再给它建索引（MySQL 5.7+/8.0 支持） - 业务层维护一个冗余字段
id_is_odd TINYINT，插入/更新时同步设置，然后查WHERE id_is_odd = 1 - 纯读多写少的场景，接受全表扫描——毕竟奇偶筛选通常不是高频核心路径
不同数据库对 MOD 的语法和行为差异
SQL Server 不支持标准 MOD() 函数，必须用 % 运算符；SQLite 支持 MOD() 但底层其实是 % 的别名；PostgreSQL 要求两个参数类型一致（比如 id::BIGINT 需匹配 2::BIGINT，否则报错）。
跨数据库项目建议统一用 % 并加注释说明意图，比强求 MOD() 更实际：
-- 筛选奇数 ID：id % 2 != 0 可覆盖所有主流数据库
真正容易被忽略的是：当 id 允许为 NULL 时，id % 2 != 0 整行会被跳过（因为 NULL 参与任何比较都为 UNKNOWN），需要显式补 OR id IS NULL 吗？不需要——除非你真想把 NULL 当作“奇数”处理，而通常不会。
