是，子查询必须用圆括号包裹，否则mysql解析器会报error 1064语法错误；无论出现在where、from、select还是四则运算中，括号都是硬性语法要求，用于明确子查询边界和运算优先级。
子查询结果直接参与四则运算时，必须用括号包裹
SQL里子查询不能像变量一样裸写在表达式中——比如 SELECT price - (SELECT cost FROM products WHERE id = 1) 会报错，因为子查询返回单值时仍需语法上视为一个“标量单元”。不加括号，解析器会把减号当作列名的一部分或产生歧义。
正确写法是给子查询加上圆括号：SELECT price - (SELECT cost FROM products WHERE id = 1) AS profit。这不仅是语法要求，也明确表达了运算优先级。
- 嵌套层级越深，括号越容易漏——建议写完立即检查每对
( )是否匹配 - 若子查询可能返回多行（如漏写
WHERE或关联条件），会触发Subquery returns more than 1 row错误，不是括号问题，而是逻辑错误 - MySQL 8.0+ 和 PostgreSQL 支持标量子查询自动降维，但 SQLite 和旧版 MySQL 仍严格要求单行单列
多层嵌套中避免重复执行相同子查询
当多个字段都依赖同一个子查询结果（比如要同时算 revenue - cost 和 revenue / cost），直接写两遍子查询不仅冗余，还可能因数据变动导致两次结果不一致（尤其在非事务快照下）。
更稳妥的做法是用派生表或 CTE 提前固化结果：
WITH base AS (
SELECT (SELECT SUM(amount) FROM sales WHERE year = 2023) AS revenue,
(SELECT SUM(expense) FROM costs WHERE year = 2023) AS cost
)
SELECT revenue - cost AS profit,
ROUND(revenue / NULLIF(cost, 0), 2) AS roi
FROM base;
- CTE 在 PostgreSQL、SQL Server、MySQL 8.0+ 中可用；SQLite 支持但不支持递归以外的复杂逻辑
-
NULLIF(cost, 0)是关键：防止除零错误，比CASE WHEN cost = 0 THEN NULL ELSE revenue/cost END更简洁 - 如果只用一次子查询，没必要强行改 CTE——简单括号足够，过度抽象反而难读
JOIN 替代相关子查询做跨表字段运算更高效
常见误区是为每个主表行执行一次子查询来取关联值，例如：SELECT id, price * (SELECT tax_rate FROM regions WHERE code = orders.region_code)。这种写法在订单表有 10 万行时，可能触发 10 万次独立子查询。
实际应优先考虑 JOIN：
SELECT o.id, o.price * r.tax_rate AS price_with_tax FROM orders o JOIN regions r ON o.region_code = r.code;
- 数据库优化器能对 JOIN 做索引合并、哈希连接等优化，而相关子查询常被迫走嵌套循环
- 若
regions表无对应region_code，JOIN会丢弃该订单行；需要保留则改用LEFT JOIN，并用COALESCE(r.tax_rate, 0)防空 - 某些场景（如子查询含聚合或窗口函数）无法直接 JOIN，此时才退回到带括号的标量子查询
注意不同数据库对 NULL 参与运算的隐式处理差异
数学运算中只要任一操作数为 NULL，绝大多数 SQL 引擎都会让整条表达式结果为 NULL。但具体表现容易被忽略：
- MySQL 中
10 + NULL→NULL；PostgreSQL 同样；但 SQLite 的NULL在某些字符串拼接场景行为略有不同（不过四则运算一致） - 若子查询返回
NULL（如没找到匹配行），price - (SELECT cost ...)整个结果就是NULL，不会报错也不会跳过 - 想把
NULL当 0 处理，必须显式写COALESCE((SELECT cost ...), 0)，不能依赖数据库默认行为 - 浮点精度问题：
ROUND()或CAST(... AS DECIMAL)要提前决定，否则99.999999999类似结果可能影响业务判断
嵌套运算本身不难，难的是在括号、NULL、性能和可维护性之间找平衡点——多数线上问题其实出在没意识到子查询被反复执行，或者忘了 NULL 会传染整个表达式。
