优先用 LEFT JOIN + WHERE B.id IS NULL 查差集，因 NOT IN 遇右表 NULL 会返回空；NOT EXISTS 更稳且不受 NULL 影响；JOIN 字段类型须严格一致，否则索引失效。
用 LEFT JOIN 找差集：为什么比 NOT IN 更可靠
直接结论：要查 A 表有、B 表没有的记录，优先写 LEFT JOIN + WHERE B.id IS NULL，别用 NOT IN —— 后者遇到 NULL 值会整个结果为空。
常见错误现象：SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users) 看似合理，但只要 users.id 里有一个 NULL，整条查询就返回空。这是 SQL 标准里 NOT IN 对 NULL 的三值逻辑决定的，不是数据库 bug。
-
LEFT JOIN明确表达“保留左表全部”，逻辑更可控 - 需要确保
ON条件里的字段在右表上建了索引（比如users.id），否则性能会断崖下跌 - 如果右表可能有重复匹配（比如一对多），
LEFT JOIN会放大左表行数，得加DISTINCT或改用NOT EXISTS
示例：
SELECT o.* FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.id IS NULL;
用 NOT EXISTS 替代 NOT IN：语义清晰且不惧 NULL
当右表子查询较复杂（含多表、聚合或条件过滤）时，NOT EXISTS 是比 NOT IN 和 LEFT JOIN 更稳的选择。
使用场景：检查“订单用户是否未被标记为 VIP”，而 VIP 列表来自带条件的子查询（如 SELECT user_id FROM tags WHERE type = 'vip'）。
-
NOT EXISTS不受右表NULL影响，语义就是“找不到匹配行” - 子查询里必须关联外层表（比如写
WHERE t.user_id = o.user_id），否则变成全量扫描 - 某些旧版 MySQL（5.6 及以前）对
NOT EXISTS优化较差，建议升级或加索引
示例：
SELECT * FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM tags t WHERE t.user_id = o.user_id AND t.type = 'vip' );
JOIN 多表做存在性检查：别让 ON 条件漏掉关键约束
多人协作时容易把存在性判断写成 INNER JOIN，结果误把“不存在”当成“不需要”，实际要的是布尔判断而非连接数据。
常见错误现象：想查“哪些商品有库存且已上架”，却写成 SELECT p.* FROM products p INNER JOIN stock s ON p.id = s.product_id —— 这只返回有库存的商品，但没体现“是否上架”的逻辑，更没法区分是缺库存还是没上架。
- 存在性检查应优先用
EXISTS或LEFT JOIN ... IS NOT NULL，避免用INNER JOIN隐式过滤 -
ON子句里不要塞业务条件（比如AND s.qty > 0），那会让LEFT JOIN失效；该放WHERE的放WHERE，该放子查询的放子查询 - 若需同时检查多个存在状态（如“有库存”且“有图片”且“有描述”），用多个
LEFT JOIN比嵌套EXISTS更易读，但注意笛卡尔风险
性能陷阱：JOIN 字段类型不一致导致索引失效
差集查询跑得慢？八成是 JOIN 字段类型不匹配，比如左表用 INT，右表用 VARCHAR，MySQL 会隐式转换，索引直接作废。
典型表现：执行计划里出现 type: ALL 或 Extra: Using where; Using join buffer，哪怕字段上有索引也白搭。
- 用
SHOW CREATE TABLE对比两边字段定义，确认类型、长度、字符集完全一致 - 字符串字段
JOIN时，注意是否含前导空格或大小写敏感（utf8mb4_0900_as_csvs_ai_ci） - 时间字段别用
datetime和timestamp混连，尤其跨时区场景下值可能错位
检查方法：
EXPLAIN SELECT ... FROM a LEFT JOIN b ON a.id = b.id;
看 key 列是否显示用了索引，rows 是否接近表总行数。
最麻烦的不是写错语法，而是字段看着一样、实际类型不同——这种问题上线后才暴露，查起来费半天劲。
