not exists比not in更稳，因not in遇子查询含null时整行判为unknown被过滤，导致漏检；not exists只判断是否存在匹配行，不受null影响，且天然短路、性能可控。
直接用 IN 或 NOT IN 做关联校验，只要子查询字段含 NULL，结果就全空——这不是 bug，是 SQL 三值逻辑的必然表现。必须改用 EXISTS / NOT EXISTS，或显式处理 IS NULL。
为什么 NOT EXISTS 比 NOT IN 更稳？
NOT IN 遇到子查询返回任意一个 NULL，整行判定为 UNKNOWN，被 WHERE 过滤掉，导致“孤儿数据”完全漏检。而 NOT EXISTS 只关心是否存在匹配行，NULL 不影响逻辑判断，天然短路，性能也更可控。
- 错误写法：
WHERE order_id NOT IN (SELECT order_id FROM shipments)—— 若shipments.order_id有NULL，结果恒为空 - 正确写法：
WHERE NOT EXISTS (SELECT 1 FROM shipments WHERE shipments.order_id = orders.order_id) - 子查询里只
SELECT 1，避免传输冗余字段；外层表字段（如orders.order_id）必须出现在子查询WHERE条件中，否则变成非相关子查询
用 LEFT JOIN + IS NULL 替代 NOT EXISTS 时要注意什么？
语义等价，但执行计划可能不同：某些优化器对 NOT EXISTS 更友好，尤其在大表上；而 LEFT JOIN 易受索引缺失或类型不一致拖累。
Coding Agent Loops
下载
一款AI工具，主要用于在持久tmux会话中运行AI编码代理(Codex、Claude Code)，使用Ralph重试循环和完成钩子处理多步骤编码任务，适合需要提升相关任务效率的用户。
- 必须确保
JOIN字段两边类型、长度、是否允许NULL完全一致，否则隐式转换会让索引失效 - 写法示例：
SELECT o.order_id FROM orders o LEFT JOIN shipments s ON o.order_id = s.order_id WHERE s.order_id IS NULL - 别写成
WHERE s.* IS NULL—— 语法错误；也别漏掉IS NULL判断，直接WHERE s.order_id = NULL永远不成立
跨表字段值一致性校验怎么防坑？
比如核对订单头金额和明细总和是否相等，不能直接 SUM() 对比，得先对齐聚合维度，再处理空值和浮点误差。
- 明细表
item_amount允许NULL？得用SUM(COALESCE(item_amount, 0))，否则SUM()会跳过整行 - 汇总表字段名、类型、精度必须和明细侧严格一致；字符型字段要统一
COLLATION，否则'ABC'和'abc'可能被当成相等 - 浮点数比对别用
=，改用ABS(a - b) ；整数字段则可直接 <code>!=
真正难的不是写出能跑的 SQL，而是确认「没漏掉任何一种不一致场景」：缺失行、值不等、NULL 处理差异、字符集隐式转换、聚合粒度错位……每种都得单独覆盖，少一个就等于放过了脏数据。
