not exists 是判断供应商“从未下单”最可靠的方式，语义清晰、优化良好，需关联外层表且避免 null 陷阱；left join + is null 需严格判断 o.supplier_id is null；lateral 仅适用于扩展逻辑；验证前须确认业务规则与数据质量。
用 NOT EXISTS 判断供应商是否“从未下单”
直接用 NOT EXISTS 是最可靠的方式，它能准确表达“一个供应商在 orders 表中找不到任何匹配记录”这个逻辑。相比 LEFT JOIN ... IS NULL，NOT EXISTS 在语义上更贴近需求，且多数数据库（如 PostgreSQL、SQL Server、Oracle）对它的优化更好，不会因重复扫描或空值陷阱出错。
常见错误是写成 NOT IN (SELECT supplier_id FROM orders) ——只要 orders.supplier_id 里有一个 NULL，整个查询就返回空结果，这是 SQL 三值逻辑的坑，务必避开。
-
NOT EXISTS子查询必须关联外层表，通常用WHERE o.supplier_id = s.id这类条件 - 子查询里只需
SELECT 1或SELECT *，不关心具体字段，数据库会忽略 SELECT 列 - 确保
suppliers.id和orders.supplier_id类型一致，否则可能隐式转换失败或索引失效
LEFT JOIN + IS NULL 的等价写法及注意事项
如果团队习惯用 LEFT JOIN，也能实现相同效果，但必须严格检查 IS NULL 的字段来源：一定要判断 orders.supplier_id IS NULL（或任意非空约束字段），而不是 orders.id IS NULL——后者在 orders 表有 id 允许为 NULL 时不可靠。
示例：
SELECT s.* FROM suppliers s LEFT JOIN orders o ON s.id = o.supplier_id WHERE o.supplier_id IS NULL;
- 必须用
o.supplier_id IS NULL，不能用o.id IS NULL（除非id是主键且不可能为NULL） - 如果
orders.supplier_id上没有索引，JOIN 可能变慢；而NOT EXISTS通常能利用supplier_id索引快速短路 - 某些 MySQL 版本在
LEFT JOIN中对WHERE条件位置敏感，把过滤条件写进ON子句会导致逻辑错误
MySQL 8.0+ 中的 LATERAL（可选但实用）
MySQL 8.0.14+ 支持 LATERAL，适合需要在子查询中引用外层字段并做额外计算的场景，比如同时查出该供应商最近一次报价时间——但单纯判断“从未下单”时没必要引入，反而增加理解成本和兼容性风险。
仅当你要扩展逻辑（例如：“从未下单，且注册超90天”）才考虑，否则坚持用 NOT EXISTS 更稳妥。
-
LATERAL不被 SQLite、旧版 MySQL 或大多数 ORM 自动识别，手工写需确认目标环境支持 - 即使支持，
NOT EXISTS的执行计划通常更简单、更易被优化器选择索引
验证结果前先检查数据质量
跑出“从未下单”的供应商列表后，别急着导出或删除，先手动验证几条：查对应 id 是否真没出现在 orders 表中，尤其注意 supplier_id 字段是否允许 NULL、是否有软删除标记（如 status != 'deleted' 被漏掉）、是否存在历史订单表（如 orders_archive）。
- 运行
SELECT COUNT(*) FROM orders WHERE supplier_id = ?验证单个 ID - 检查
suppliers表中是否有状态字段（如is_active），避免把已停用但曾下过单的供应商误判为“从未下单” - 若业务中存在“预下单”或“草稿订单”，确认这些记录是否计入
orders表，以及它们的status是否影响判断逻辑
真正麻烦的从来不是语法，而是业务规则怎么定义“订单”——是只要插入就算，还是必须 status = 'confirmed'？这点不厘清，再正确的 SQL 也会查错人。
