WHERE 条件写错位置，查不到数据是常态，不是你手误——而是逻辑没理清。
WHERE 和 LEFT JOIN ON 的条件别混着放
很多人写
LEFT JOIN时，把本该过滤右表的条件（比如
status_riwayat = 'keluar'）硬塞进
ON子句，结果发现只返回一条记录，或者
masuk数据直接消失。这不是 bug，是 SQL 执行顺序决定的：ON 先匹配，WHERE 后过滤。
ON中加条件 → 右表不满足就“变 NULL”，但左表记录仍保留（符合 LEFT JOIN 语义）
WHERE中加右表字段条件 → 整行被过滤掉（哪怕左表有数据），等价于
INNER JOIN想同时显示
masuk和
keluar的历史记录？条件必须挪到
WHERE，且确保左表主键能对齐
正确写法示例：
SELECT d.*, r.status_riwayat, r.jumlah, r.sisa
FROM pj_detailsupplier d
LEFT JOIN pj_riwayat r ON d.id_detailsupplier = r.id_detailsupplier
WHERE d.id_barang = 205
AND r.status_riwayat IN ('masuk', 'keluar');
多条件组合时，AND/OR 优先级容易翻车
写
WHERE age > 25 AND sex = 'male' OR department = 'HR'，你以为是「男且大于25」或「HR部门」，实际执行顺序是
(age > 25 AND sex = 'male') OR department = 'HR'—— 看似合理，但一旦漏括号，逻辑就偏了。 用
OR连接不同维度条件时，务必用括号明确分组 避免混合使用
AND和
OR而不加括号，MySQL 不会报错，但结果常出人意料 不确定时，用
EXPLAIN看执行计划，确认是否真按你设想的逻辑走
空值（NULL）会让 WHERE 条件静默失效
WHERE status_riwayat = 'masuk'查不到任何记录？先查查这个字段是不是有很多
NULL。因为
NULL = 'masuk'永远返回
UNKNOWN，不是
TRUE，所以整行被过滤。 判断空值必须用
IS NULL或
IS NOT NULL，不能用
= NULL如果想把
NULL当作某个值参与查询，可用
COALESCE(status_riwayat, 'unknown')联合索引中含可空字段时，
WHERE条件若涉及该字段的非空判断，可能无法命中索引最左前缀
IN 和 = 的性能差异在大数据量下很真实
查 10 个部门用
WHERE department IN ('HR','IT','Finance',...) 没问题；但查 5000 个 ID 时，IN会退化成逐个比对，尤其当右边是子查询（
IN (SELECT ...)）更慢。 超过几百个值，优先考虑用临时表 +
JOIN替代
IN
IN列表里的值类型要和字段一致，否则隐式转换导致索引失效（比如字段是
INT，却传字符串
'123'） 确定唯一匹配时，
=比
IN更快、更安全，也更容易被优化器识别为常量传播
真正卡住人的，往往不是语法记不住，而是 WHERE 在整个查询流程中的“作用时机”被忽略了——它发生在 JOIN 之后、GROUP BY 之前，且对 NULL 和类型极其敏感。动手前，先问一句：这个条件，是想筛行，还是筛组？是想留空，还是必须有值？
