SQLite中GROUP BY结果异常主因是隐式列依赖、NULL处理或JOIN顺序导致逻辑偏差，非语法错误；需确保非聚合列全在GROUP BY中、避免表达式分组、用CTE物化子查询、显式JOIN链及CASE防NULL除零。
GROUP BY 在 SQLite 中出结果异常，通常不是语法写错，而是隐式列依赖、NULL 处理或连接顺序导致的逻辑偏差——尤其在多表 JOIN + 子查询嵌套时，GROUP BY 的作用域容易被误判。
GROUP BY 后 SELECT 列不匹配报错或数据错乱
SQLite 严格遵循“所有非聚合列必须出现在 GROUP BY 中”，但它的错误提示往往不直接说“列不在 GROUP BY 中”，而是返回空结果、重复行，或抛 no current row 这类底层 Cursor 异常（尤其用 SQLiteDataAdapter.Fill() 时）。
- 检查
SELECT中每个非聚合字段（如b.OrgName、c.je）是否都出现在GROUP BY列表里；漏一个就可能让 SQLite 任意选值，或触发内部校验失败 - 避免在
GROUP BY里写表达式（如GROUP BY b.OrgId, c.dwid没问题，但GROUP BY b.OrgId || '_x'会破坏分组语义） - 如果用了子查询生成临时列（如
(SELECT parentorgid FROM kj_orginfo WHERE orgid = j.dwid)），它不能直接进GROUP BY，得先在子查询里GROUP BY或用别名提取
LEFT JOIN + GROUP BY 导致行数异常或 no current row
这是你知识库中提到的典型场景：用 LEFT JOIN 关联主表和聚合子查询后，GROUP BY 仍按主表粒度分组，但子查询结果为空时，ifnull(a.bds,0) 看似安全，实际可能因 JOIN 顺序导致 SQLite 无法对齐行——尤其当子查询没数据，而主表有匹配行时，Fill(dt) 可能拿到空 Cursor。
- 把聚合子查询提前物化成 CTE（SQLite 3.8.3+ 支持）：
WITH a AS (SELECT orgid, sum(bds) bds ...)，再LEFT JOIN a ON ...，避免子查询在 JOIN 中动态执行 - 确认 JOIN 表顺序：SQLite 对
FROM t1, t2 LEFT JOIN t3这种混合写法解析不稳定，应统一用显式JOIN链，且主表放在最左（如FROM KJ_OrgInfo b LEFT JOIN (...) a ON ... INNER JOIN jdjh c ON ...） - 用
EXISTS替代LEFT JOIN查空值场景：比如只关心“有预算的部门”，改用WHERE EXISTS (SELECT 1 FROM jdjh c WHERE c.dwid = b.orgid AND c.nd='2015')，避开空关联干扰分组
聚合函数内 NULL 值引发除零或结果失真
ifnull(c.je,0) 看似防错，但 a.bdje*100/c.je 在 c.je 为 0 时仍会报错，且 SQLite 不自动跳过 NULL 分母——这常导致整条记录被丢弃，Fill() 返回空 DataTable。
- 用
CASE WHEN c.je != 0 THEN a.bdje*100/c.je ELSE 0 END替代裸除法，明确控制 NULL/零分支 - 聚合前先过滤掉无效数据：
WHERE c.je IS NOT NULL AND c.je > 0，比事后 ifnull 更可靠 - 注意
SUM()和COUNT()对 NULL 的不同行为：SUM(col)忽略 NULL，COUNT(col)也忽略 NULL，但COUNT(*)统计所有行——混用易造成数值偏差
真正卡住的地方往往不是 GROUP BY 本身，而是它和 JOIN、子查询、NULL 处理的组合效应。调试时优先用 SQLite CLI 直接跑 SQL，看原始结果集结构，再反推 .NET 层适配逻辑——很多 no current row 其实是上层代码没处理空结果集，而非 SQL 本身错误。
