MOD()函数判断奇偶性最直接：整数对2取模结果为1是奇数、为0是偶数；需注意NULL值被自动过滤，浮点或字符串列须先转整数（如FLOOR），且MOD(col,2)=1可能使索引失效。
用 MOD() 函数判断奇偶性最直接
SQL 中没有内置的 IS_ODD() 这类函数，但所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都支持取模运算符或函数，MOD() 或 % 是筛选奇数列的核心工具。原理很简单：一个整数对 2 取模结果为 1，就是奇数；为 0 就是偶数。
注意：如果列可能含 NULL，MOD(col, 2) = 1 会跳过这些行（因为 NULL = 1 恒为 UNKNOWN），这是预期行为，无需额外处理，除非业务明确要求保留 NULL。
示例（MySQL/PostgreSQL）：
SELECT * FROM orders WHERE MOD(amount, 2) = 1;
SQL Server 用户需改用 % 运算符：
SELECT * FROM orders WHERE amount % 2 = 1;
当数值列是浮点型或字符串时要先转换
如果列类型是 DECIMAL、FLOAT 或 VARCHAR，直接套用 MOD() 可能报错或逻辑错误——比如 MOD(3.7, 2) 在 PostgreSQL 中返回 1.7，不是你想要的“整数位奇偶性”。
正确做法是先转成整数再判断，但转换方式有坑：
-
CAST(col AS INTEGER)或ROUND(col)：适用于想按四舍五入后取整判断 -
FLOOR(col)：向下取整，适合只关心整数部分（如金额字段存为199.99，应视为 199） - 避免用
TRUNCATE(col, 0)（MySQL）或TRUNC(col)（Oracle），语义更清晰
安全写法（兼容多数数据库）：
SELECT * FROM sales WHERE MOD(FLOOR(price), 2) = 1;
WHERE 条件中使用函数可能影响索引效率
如果 amount 列上有索引，写成 MOD(amount, 2) = 1 通常会导致索引失效（全表扫描），尤其在大数据量表中明显变慢。
优化思路不是“避免用 MOD”，而是看业务是否允许冗余字段：
- 加一个计算列（如
is_odd_amount AS (CASE WHEN amount % 2 = 1 THEN 1 ELSE 0 END)），并为其建索引（MySQL 5.7+/PostgreSQL 支持） - 或在应用层预计算并存为布尔字段（如
amount_is_odd），查询时直接WHERE amount_is_odd = 1 - 若只是偶尔查、数据量小（
不同数据库对负数取模的处理不一致
这是最容易被忽略的陷阱。例如 MOD(-3, 2)：
- MySQL / PostgreSQL 返回
1（符合数学定义：-3 = (-2)×2 + 1） - SQL Server 返回
-1（-3 % 2 = -1），此时WHERE col % 2 = 1会漏掉负奇数
跨数据库可移植写法是统一用绝对值判断：
WHERE ABS(col) % 2 = 1
但要注意：ABS() 同样有函数索引问题；且如果业务中根本不会出现负数（如金额、数量），这步可省。
实际项目里，先确认该列的业务取值范围比盲目写通用逻辑更重要。
