子查询作计算列必须用括号包裹且为标量，即返回单行单列；应使用聚合函数兜底并内置库存状态判断逻辑，避免外层加工。
子查询当计算列时必须用括号包裹
SQL 不允许把裸子查询直接当列值用，否则会报 Operand should contain 1 column(s) 或语法错误。子查询作为计算列，本质是标量子查询（必须返回且仅返回一行一列），所以必须加括号，让引擎明确这是个表达式。
常见错误写法：SELECT name, (SELECT SUM(qty) FROM stock_log WHERE item_id = items.id) AS total_in FROM items —— 看似对，但一旦子查询可能返回多行（比如漏了 WHERE 或关联条件有误），就会崩。正确做法是确保子查询严格单值，或用聚合兜底。
- 始终用
(SELECT ...)形式，不能省略外层括号 - 若子查询可能无结果，
SUM()、COUNT()等聚合函数会返回NULL，不是报错，这是安全的 - 避免在子查询里用
ORDER BY或LIMIT（除非配合ROW_NUMBER()窗口函数，但那就不是标量了）
库存状态逻辑得放在子查询里，别靠外部 CASE
有人习惯先查出原始库存数，再用应用层或外层 CASE WHEN 判断“充足/紧张/缺货”，但这会让逻辑分散、难以复用。更健壮的做法是把判断规则直接塞进子查询，让每一行库存状态都是实时计算出来的确定值。
比如判断逻辑：当前可用库存 ≤ 5 → “缺货”，≤ 20 → “紧张”，否则 → “充足”。这个分支必须在子查询内部完成，而不是依赖外层对 available_qty 列再加工。
- 子查询内用
CASE WHEN (SELECT COALESCE(SUM(qty), 0) FROM stock_log ...) - 注意
COALESCE防NULL，否则NULL 结果是 <code>UNKNOWN，整个CASE可能掉进ELSE分支或返回NULL - 不要在子查询里调用非确定性函数（如
NOW()），除非你真需要每行都实时算——这会影响执行计划和缓存
性能瓶颈通常出在子查询没走索引
每个主表行都会触发一次子查询执行（即“相关子查询”），如果子查询里的 WHERE 条件字段没索引，或者关联方式导致无法使用索引（比如用了函数包装字段），查询会从 O(n) 退化成 O(n×m)。
典型慢场景：(SELECT SUM(qty) FROM stock_log WHERE item_id = items.id AND type = 'in') —— 若 stock_log(item_id, type) 没联合索引，MySQL 很可能全表扫 stock_log 每次。
- 给子查询中所有
WHERE和JOIN字段建合适索引，优先联合索引（顺序按等值条件→范围条件） - 避免在子查询
WHERE里对字段做运算，比如WHERE YEAR(created_at) = 2024会失效索引，改用WHERE created_at >= '2024-01-01' AND created_at - 用
EXPLAIN看子查询是否命中type=ref或range，而不是ALL
用 LEFT JOIN + 聚合替代子查询更可控
当子查询逻辑变复杂（比如要同时算入库、出库、锁定量），嵌套多层子查询不仅难读，优化器也容易失智。此时把子查询“外提”为 LEFT JOIN，再用 GROUP BY 聚合，语义清晰、执行计划稳定。
例如：主表 items 关联 stock_log 计算三类数量，用子查询就得写三个独立 (SELECT ...)；而用 LEFT JOIN 只需一次关联，再用 SUM(IF(...)) 分条件聚合。
-
LEFT JOIN保证主表行不丢失，即使某 item 在stock_log中无记录 - 聚合前务必
GROUP BY items.id，否则结果行数错乱 - 若只想要最新一条状态（如最后更新时间、最后操作人），子查询反而更自然，这时别硬套
JOIN
