where条件写错或字段类型不匹配导致结果偏差：字符串查整型字段时mysql隐式转换而postgresql不匹配；日期漏时间部分会丢数据；null需显式处理；limit必须配order by防随机；子查询必写关联条件，否则笛卡尔积；not in遇null返回空，应改用not exists。
WHERE条件写错或字段类型不匹配
结果“不对”但没报错，大概率是过滤逻辑本身就有偏差。比如 WHERE status = '1' 用字符串查整型字段，MySQL 可能隐式转换但 PostgreSQL 直接不匹配；又或者 WHERE created_at > '2024-01-01' 没加时间部分，实际漏掉当天 00:00:00 之后的数据。
- 用
SELECT * FROM table WHERE ... LIMIT 1单独执行条件片段，确认返回是否符合预期 - 检查字段实际类型：
DESCRIBE table_name或SHOW COLUMNS FROM table_name - 字符串值必须加引号，数字不要加引号，日期建议用标准格式
'2024-01-01 00:00:00' - 注意 NULL 处理：
status != 'done'会漏掉NULL行，要显式写status != 'done' OR status IS NULL
ORDER BY 缺失导致 TOP/LIMIT 结果随机
SELECT TOP 5 * 或 SELECT * LIMIT 5 不带 ORDER BY，数据库不保证顺序——不是“前5条”，而是“任意5条”。尤其在有索引变动、统计信息更新或分布式节点上，每次结果都可能不同。
- 只要用了
LIMIT、TOP、FIRST，必须配ORDER BY字段 - 分页时避免仅靠
ORDER BY created_at：重复值会导致跳行或重复，应追加唯一字段如ORDER BY created_at DESC, id DESC - MySQL 8.0+ 和 PostgreSQL 支持
OFFSET，但大数据量下仍建议改用游标分页（如WHERE id > last_id ORDER BY id LIMIT 10）
子查询漏关联字段引发笛卡尔积
外层查用户，子查询查每个用户的最新订单，但子查询里没写 WHERE user_id = u.id，结果就是子查询对每个用户都跑一遍全表扫描，最后取的其实是某次随机匹配的单条记录。
- 所有相关子查询（即引用外层字段的子查询），WHERE 或 ON 中必须显式写出等值关联条件
- 用
EXPLAIN看执行计划：如果子查询显示type: ALL且没有ref或eq_ref，基本可判定缺关联 - 优先用
JOIN替代相关子查询，特别是要聚合或排序时——语义更清晰，优化器也更容易命中索引 - 别用
NOT IN (subquery)：子查询返回任何NULL，整个表达式变UNKNOWN，结果为空；改用NOT EXISTS
聚合查询 GROUP BY 不完整或字段引用混乱
子查询里写了 GROUP BY order_date 和 MAX(amount)，但外层 SELECT 又只取了 MAX(amount)，没取 order_date，MySQL 5.7+ 会报错，低版本则返回不可靠的任意一行。
- 子查询含聚合时，外层引用的所有非聚合字段，必须全部出现在子查询的
GROUP BY列表中 - 禁止在子查询里写
SELECT *：外层无法判断哪些字段参与分组，极易出错 - 用 CTE 显式命名中间结果，比嵌套子查询更容易核对字段来源和分组逻辑
-
ORDER BY+LIMIT在子查询中可能被优化器忽略——标准 SQL 不允许在子查询中用ORDER BY控制最终顺序，真要取最新一条，得用窗口函数或 JOIN 关联主键
真实场景里最容易被忽略的，是子查询里那个看似无关紧要的关联条件缺失，以及聚合查询中外层对子查询字段的“想当然”引用——这两处不报错，但数据错得毫无征兆。
