where条件位置错误导致查不到数据是因逻辑不清而非手误：on中右表条件使右表变null但左表保留，where中则整行过滤；空值需用is null判断；多条件须加括号；in列表过大应改用临时表join。
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 和类型极其敏感。动手前，先问一句：这个条件，是想筛行，还是筛组？是想留空，还是必须有值？
