MOD函数在WHERE子句中通过MOD(id, 2) = 0（偶数）或MOD(id, 2) = 1（奇数）判断奇偶性，需注意数据库方言差异、NULL值导致行被静默过滤，以及大表中索引失效问题。
MOD函数在WHERE子句中直接判断奇偶性
SQL里用MOD()（或%）筛选奇偶数，核心是看余数是否为0。多数数据库（PostgreSQL、MySQL 8.0+、SQL Server、Oracle）支持MOD(n, 2)；MySQL早期版本和SQLite则常用n % 2。
实际写法要匹配你的数据库方言：
- PostgreSQL / Oracle：用
MOD(id, 2) = 0查偶数，MOD(id, 2) = 1查奇数 - MySQL（所有版本）：可统一用
id % 2 = 0，更简洁且兼容性好 - SQL Server：
id % 2可用，但注意NULL参与运算结果为NULL，需额外处理
示例（查偶数ID）：
SELECT * FROM users WHERE id % 2 = 0;
处理NULL值导致漏数据的问题
id % 2遇到NULL会返回NULL，而WHERE条件中NULL = 0判定为FALSE，整行被过滤掉——这不是bug，是三值逻辑的正常表现，但容易误以为“没查到”，实则是NULL记录被静默丢弃了。
若字段可能为NULL，必须显式声明意图：
- 只想要明确的偶数：保持
id % 2 = 0，NULL自然排除 - 想把
NULL也纳入结果（比如视作“未知”）：改用COALESCE(id % 2, -1) = 0，或拆开写(id % 2 = 0) OR (id IS NULL) - 检查是否真有
NULL：先执行SELECT COUNT(*) FROM table WHERE id IS NULL;
ORDER BY里用MOD做交替排序（比如分组轮播）
MOD不只用于过滤，还能配合ORDER BY实现模式化排序。例如按创建时间升序，但希望用户列表中奇数位显示A类用户、偶数位显示B类用户，可借助行号与MOD组合：
PostgreSQL示例（用窗口函数生成序号）：
SELECT *, ROW_NUMBER() OVER (ORDER BY created_at) AS rn FROM users ORDER BY MOD(rn, 2), created_at;
注意点：
- MySQL 8.0+才支持窗口函数，旧版需用变量模拟，稳定性差
-
MOD(rn, 2)让偶数序号（2,4,6…）排前面，再按created_at微调，不是简单“隔行取” - 这种写法性能随数据量上升明显下降，千万级表慎用
替代方案：用位运算提升性能（仅限整数主键）
对超大表，id % 2虽直观，但某些引擎（如MySQL InnoDB）无法利用索引加速模运算。此时可考虑位与操作：(id & 1) = 0等价于偶数判断，原理是二进制末位为0即偶数。
优势与限制：
- 几乎所有SQL引擎都支持
&位运算，且通常比%快一点（尤其主键有索引时） - 仅适用于非负整数；负数位运算行为因数据库而异（PostgreSQL支持负数
&，MySQL不推荐） - 可读性略低，团队协作时建议加注释，比如
-- 用位与判断偶数，等价于 id % 2 = 0
真正影响性能的往往不是%本身，而是缺少索引或全表扫描——先确认执行计划里是否走了索引，再决定要不要换位运算。
奇偶筛选本身很简单，难的是想清楚NULL要不要算、性能瓶颈在哪、以及不同数据库对MOD和%的细微差异。动手前，先SELECT pg_typeof(col)或DESCRIBE table看看字段类型和空值情况。
