not exists 优于 not in 是因后者遇 null 返回 unknown 致结果为空，而前者仅判断子查询是否存在匹配行，不受 null 影响，语义清晰、性能更优且跨库一致。
为什么用 NOT EXISTS 而不是 NOT IN
直接用 NOT IN 查没有订单的客户，很容易漏掉结果——只要订单表里 customer_id 有 NULL，整个查询就返回空。这是 SQL 标准行为：value NOT IN (1, 2, NULL) 永远是 UNKNOWN，不满足 WHERE 条件。
NOT EXISTS 完全绕过这个问题，它只关心子查询是否“能找到匹配行”，不依赖值比较，语义更清晰、结果更可靠。
- 推荐写法：
SELECT * FROM customers c WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id) - 别写：
SELECT * FROM customers WHERE id NOT IN (SELECT customer_id FROM orders)（除非你 100% 确认orders.customer_id非空） - 子查询里用
SELECT 1就够了，不用SELECT *或具体字段，数据库优化器更容易跳过实际数据读取
用 LEFT JOIN + IS NULL 也行，但要注意连接条件
这是另一种直观解法：把客户左连订单，再筛出订单侧为空的记录。但新手常在这里写错 ON 条件或漏掉 WHERE 判断位置。
- 正确写法：
SELECT c.* FROM customers c LEFT JOIN orders o ON c.id = o.customer_id WHERE o.customer_id IS NULL - 错误写法：
... LEFT JOIN orders o ON c.id = o.customer_id WHERE o.id IS NULL（o.id可能为NULL即使有订单，不可靠） - 如果
orders表很大，LEFT JOIN可能比NOT EXISTS多扫描数据，尤其没建好索引时
性能关键：给 orders.customer_id 加索引
无论选 NOT EXISTS 还是 LEFT JOIN，数据库都要频繁按客户 ID 查订单。没索引的话，每次子查询或连接都可能触发全表扫描。
- 执行前先确认：
SHOW INDEX FROM orders，看有没有customer_id单列索引或作为前导列的复合索引 - 如果没有，加一个：
CREATE INDEX idx_orders_customer_id ON orders(customer_id) - 注意：如果
orders表已有(customer_id, status)这样的复合索引，通常也能用上，不必重复建单列索引
客户表和订单表字段名不叫 id/customer_id 怎么办
实际项目里表结构五花八门：可能是 cust_no、client_id、user_id……别硬套示例名，得看自己库里的真实字段。
- 先查字段：
DESCRIBE customers和DESCRIBE orders，确认关联字段名和类型是否一致（比如一个是INT，另一个是BIGINT就可能隐式转换失败） - 如果订单表用的是
user_id关联客户主键，那就写o.user_id = c.id，而不是想当然填customer_id - 大小写敏感？MySQL 默认不区分，但 PostgreSQL 或启用了
lower_case_table_names=0的 MySQL 会区分，字段名写错直接报Unknown column
实际跑之前，先在小数据集上 EXPLAIN 一下，看执行计划里有没有 type: ALL 或 Extra: Using filesort——那基本说明索引没生效或者写法触发了低效路径。
