必须用row_number()生成行号再取模（如mod(rn,2)=1筛选奇数行），直接对id等字段取模仅按其值奇偶过滤，无法保证结果集物理顺序的奇偶行。
MOD函数在SQL中怎么判断奇偶行
直接用 MOD(row_number() OVER (ORDER BY ...), 2) 得到 0 或 1，就能区分奇偶——这是最可靠的方式。别用 MOD(id, 2)，因为主键可能不连续、有删改、或根本没按顺序插入。
常见错误是直接对业务字段（比如 MOD(order_id, 2)）取模，结果看着像交替，实际只要数据删过、跳过编号，立刻错乱。真正要“视觉上逐行交替”，必须基于查询时动态生成的行号。
-
row_number()必须带OVER子句，且ORDER BY要明确（哪怕只是ORDER BY id），否则行号不稳定 - PostgreSQL 和 SQL Server 支持
MOD()，MySQL 用%运算符（row_number() OVER (...) % 2），Oracle 同样用MOD() - 返回值：偶数行为 0，奇数行为 1（注意不是 1/2），前端或报表工具据此设背景色
报表工具里怎么接SQL返回的奇偶标识
多数报表工具（如 JasperReports、Power BI、帆软）支持根据字段值设置条件样式。你只需让SQL多返回一列，比如 is_odd：
SELECT *, MOD(row_number() OVER (ORDER BY created_at, id), 2) AS is_odd FROM orders;
然后在工具里把 is_odd = 1 的行设为浅灰背景，is_odd = 0 设为白色。别试图在SQL里拼HTML或CSS类名——耦合太紧，维护困难，也容易被SQL注入规则拦截。
- 字段别名必须清晰（如
is_odd），避免用mod_result这种模糊名 - 如果报表分页，确保
row_number()的OVER子句不含分页逻辑（即不在子查询里先 limit 再 row_number），否则每页都从 1 开始，奇偶就断了 - 某些旧版工具不识别窗口函数，得用变量模拟（MySQL 5.7 以下），但性能差、并发不安全，优先升级或换方案
为什么不能用 WHERE MOD(...) 过滤奇偶行
想只查奇数行？写 WHERE MOD(row_number() OVER (...), 2) = 1 会报错——绝大多数数据库不允许在 WHERE 中直接用窗口函数。这是语法限制，不是写法问题。
真要过滤，必须套一层子查询或 CTE：
WITH numbered AS ( SELECT *, row_number() OVER (ORDER BY id) AS rn FROM products ) SELECT * FROM numbered WHERE MOD(rn, 2) = 1;
- CTE 方式最通用，SQL Server、PostgreSQL、Oracle 都支持；MySQL 8.0+ 也支持
- 别用
SELECT * FROM t WHERE @row := @row + 1 AND MOD(@row, 2) = 1这类用户变量方案——执行计划不可控，排序失效时结果随机 - 如果表很大，
row_number()全量排序成本高，纯奇偶过滤需求建议前端分页后处理，而非SQL层硬扛
兼容性与性能容易被忽略的点
SQLite 没有 row_number()（直到 3.25.0 才支持），老版本只能靠自关联或子查询模拟，慢且易出错。这时候不如放弃SQL层奇偶标记，交给应用层或前端渲染时判断索引位。
- MySQL 5.7 及更早：没有窗口函数，
MOD(@i:=@i+1, 2)是唯一选择，但必须加ORDER BY+SELECT强制变量初始化，且不能用于视图或存储过程内部 - 即使支持窗口函数，
ORDER BY字段如果有 NULL，不同数据库对 NULL 排序位置处理不同（有的放最前，有的最后），会导致奇偶错位——务必显式写ORDER BY col ASC NULLS LAST（PostgreSQL）或等效处理 - 如果报表要导出 Excel，奇偶着色通常由工具自动处理，SQL里加
is_odd列反而冗余，除非导出格式需保留样式逻辑
