先说结论：嵌套查询虽然语法简洁，适合轻量级的库存预警场景，但在实际应用中，单值约束、NULL逻辑以及性能问题往往成为隐患。更关键的是，如果WHERE子句中的子查询返回多行，系统会直接报错——这是初学者最容易踩的雷区。
通过SQL嵌套查询，可以在查询过程中直接完成阈值比对，从而实现自动化的库存预警。然而在轻量级预警场景下，单值约束、NULL逻辑或性能瓶颈很容易让这种方案失效——它更适用于小规模、低频的预警任务，若涉及高频或大数据量场景，建议另寻更高效的方案。
WHERE子句里的子查询必须返回单值
一个常见误区是：SELECT * FROM inventory WHERE stock_qty < (SELECT alert_value FROM thresholds)，结果报错 Subquery returns more than 1 row。这说明thresholds表中缺少限制条件，导致返回了多行结果。
- 如果阈值按商品配置，子查询必须带上
WHERE product_id = i.product_id，且product_id在thresholds表上需建有唯一索引。 - 如果阈值是全局统一值（比如所有商品的警戒线均为5），直接写
stock_qty < 5即可，不必硬套子查询。 - 若子查询结果为NULL（例如某商品未配置阈值），整个表达式会被判为UNKNOWN，该行不会被查出——这不是bug，而是SQL三值逻辑的正常表现。
用LEFT JOIN替代相关子查询提升性能
当inventory表数据量超过万级时，WHERE中每行都执行一次子查询会产生DEPENDENT SUBQUERY，执行速度会慢3到10倍。
- 改用
LEFT JOIN thresholds t ON i.product_id = t.product_id，让优化器一次性走索引联结，从而提升SQL查询性能。 - 务必为thresholds.product_id加索引，否则JOIN会退化为全表扫描，影响预警响应速度。
- 使用
COALESCE(t.alert_value, 10)处理缺失阈值，避免用0导致所有无配置商品都被误报为库存预警。 - SQLite不支持在WHERE中用COALESCE推导索引，此时建议先
SELECT product_id FROM thresholds获取有阈值的商品集合，再查询库存数据。
多维度阈值匹配时别硬关联product_id
实际业务中，预警值常按品类、仓库或供应商维度配置，并非每个商品都有独立记录。强行用product_id关联会导致漏数据或错配。
- 先明确业务规则：预警到底归属哪个维度？比如按品类，则关联路径为inventory → categories → thresholds。
- 典型写法：
JOIN categories c ON i.category_id = c.id JOIN thresholds t ON c.category_code = t.scope_value WHERE t.scope_type = 'category'。 - 字段名如scope_type、scope_value是通用设计，具体需以你库中实际字段为准。
- 若一个商品匹配多个阈值（如同时命中品类和供应商规则），需约定优先级，可用
ROW_NUMBER() OVER (PARTITION BY i.product_id ORDER BY priority DESC)取最高优先级的一条记录。
嵌套查询看起来简洁明了，但真正上线时最容易栽在“阈值来源不唯一”和“NULL语义被忽略”这两点上——查不出数据时，先检查子查询是否真的只返回一行，再看有没有NULL干扰判断逻辑。
