<p>直接在WHERE子句中用子查询比较库存与预警值，无需创建视图或临时表，如SELECT * FROM inventory WHERE stock_qty < (SELECT alert_value FROM config);</p>
WHERE子句里直接用子查询比较库存和预警值
别绕弯写视图或临时表，多数场景下 SELECT * FROM inventory WHERE stock_qty 就够用。关键在子查询必须返回单值，否则会报错 <code>Subquery returns more than 1 row。
常见错误是阈值表里同一 product_id 存多条记录，或没加 WHERE 条件导致子查询返回整列。务必确认阈值表主键或唯一约束落在 product_id 上。
- 如果阈值是全局统一值（比如所有商品都按 5 为警戒线），直接写
stock_qty ，别硬套子查询 - 若阈值表存在 NULL，子查询结果为 NULL 时整个条件判为 FALSE，该商品不会被查出——这是 SQL 的三值逻辑，不是 bug
- MySQL 8.0+ 和 PostgreSQL 支持 LATERAL，但简单预警场景没必要，JOIN 更直观
用 LEFT JOIN 替代相关子查询提升性能
当库存表数据量超过万级，上面的子查询可能每行都触发一次阈值表扫描，执行计划里常出现 DEPENDENT SUBQUERY。换成 LEFT JOIN 让优化器一次性走索引联结，速度通常快 3–10 倍。
示例：SELECT i.* FROM inventory i LEFT JOIN thresholds t ON i.product_id = t.product_id WHERE i.stock_qty 。注意这里用 <code>COALESCE 处理阈值缺失的情况，避免因 NULL 导致漏数据。
-
thresholds.product_id字段必须有索引，否则 JOIN 变全表扫描 - 如果某些商品没配预警值，
COALESCE(t.warning_level, 0)会让它们永远满足stock_qty 条件——这显然不合理，应改用业务认可的默认值，比如 <code>COALESCE(t.warning_level, 10) - SQLite 不支持
COALESCE在 WHERE 中推导索引，此时建议先过滤出有阈值的商品再查
处理阈值表结构不一致的现实情况
实际系统里阈值未必按 product_id 存，可能是按品类、仓库、供应商维度配置。这时硬关联 product_id 会漏数据或错配。得先明确业务规则：预警值到底归属哪个维度？
例如按品类预警，SQL 得改成 SELECT i.* FROM inventory i JOIN categories c ON i.category_id = c.id JOIN thresholds t ON c.category_code = t.scope_value WHERE t.scope_type = 'category' AND i.stock_qty 。
- 字段名如
scope_type、scope_value是常见设计，但具体名称以你库中为准，别凭空写category_code - 如果一个商品同时匹配多个阈值（比如既有品类阈值又有供应商阈值），需约定优先级，用
ROW_NUMBER() OVER (PARTITION BY i.product_id ORDER BY priority DESC)取最高优的一条 - 别在应用层拼 SQL 判断维度类型，这种逻辑放数据库里更可靠
警惕浮点数和单位不一致引发的误判
库存字段是 DECIMAL(10,3)，预警值却是 FLOAT，或者库存单位是“件”、预警单位是“箱”（1 箱 = 12 件），查询结果就会错得离谱。这不是语法问题，而是数据语义没对齐。
检查手段很简单：SELECT stock_qty, warning_level, stock_qty ，肉眼扫几行就能发现数值量级是否合理。
- 如果预警值存的是“箱”，库存是“件”，WHERE 条件得写成
i.stock_qty - MySQL 中
DECIMAL和FLOAT混算可能隐式转为浮点，导致0.1 + 0.2 != 0.3，一律显式转CAST(t.warning_level AS DECIMAL) - 前端显示“库存不足”时，最好把当前库存、预警值、单位一并返回，方便排查到底是数据问题还是逻辑问题
实际跑之前，先用 EXPLAIN 看执行计划，重点盯有没有 type=ALL 或 Extra 里带 Using filesort。阈值逻辑看着简单，踩进数据模型和精度陷阱里，比写个存储过程还容易翻车。
