子查询不能直接引用外层表字段，须用相关子查询（如where r.product_id = p.id）或exists；多级fallback推荐coalesce配合单行保证（limit 1/聚合/唯一条件）；关联字段必须建索引（单列或组合）；update慎用子查询，优先join并加where限定。
子查询里不能直接引用外层表字段？用 EXISTS 或相关子查询替代
MySQL 和 PostgreSQL 中，普通非相关子查询（即子查询不依赖外层表）无法访问外层 SELECT 或 WHERE 中的列。如果你写成 SELECT *, (SELECT price * 1.1 FROM pricing_rules WHERE product_id = products.id) FROM products，在某些版本会报错或返回 NULL——因为子查询没声明与外层的关联关系。
- 必须显式建立关联：用
WHERE子句让子查询中的条件引用外层表别名，例如WHERE r.product_id = p.id - 优先用
EXISTS判断规则是否存在，再用相关标量子查询取值，避免因多匹配导致错误结果 - PostgreSQL 支持 LATERAL，MySQL 8.0+ 支持
FROM ... JOIN LATERAL，但多数业务场景用标准相关子查询更稳妥
调价逻辑嵌套多层时，COALESCE 比 IFNULL 更安全
实际业务中常有“优先用促销规则，无则用类目基准价，再无则用原始价”的链式 fallback。如果直接用 IFNULL((SELECT …), IFNULL((SELECT …), price))，一旦某个子查询返回多行，整个语句会报错 Subquery returns more than 1 row。
- 每个子查询必须确保最多返回一行：加
LIMIT 1或用MAX()/MIN()聚合，或在WHERE中加唯一性约束（如AND status = 'active' AND valid_from = NOW()'） -
COALESCE本身不解决多行问题，但它能清晰表达 fallback 顺序，配合单行保证才真正可靠 - SQL Server 用
ISNULL，Oracle 用NVL，跨数据库项目建议统一用COALESCE
性能崩了？给子查询里的关联字段加索引
一个典型慢查询是 SELECT p.*, (SELECT new_price FROM price_adjustments pa WHERE pa.product_id = p.id ORDER BY priority DESC LIMIT 1) AS adjusted_price FROM products p。当 products 有 10 万行、price_adjustments 有 50 万行时，没索引会导致全表扫描 × 10 万次。
- 必须在子查询的
WHERE条件字段上建索引，例如CREATE INDEX idx_pa_product_id ON price_adjustments(product_id) - 若还按
priority排序取第一行，组合索引更优：CREATE INDEX idx_pa_product_priority ON price_adjustments(product_id, priority DESC) - 注意 MySQL 的隐式排序优化：
ORDER BY … LIMIT 1在有合适索引时可跳过排序，否则仍会临时排序
动态调价结果要写回原表？别直接 UPDATE ... SET price = (SELECT ...)
看似简洁的写法 UPDATE products SET price = (SELECT new_price FROM pricing_rules WHERE product_id = products.id) 风险极高：子查询没匹配时设为 NULL，且无法控制更新范围（比如只想调库存 > 0 的商品）。
- 先用
SELECT验证子查询逻辑和结果集大小，确认只影响目标行 - 改用
JOIN形式更新：UPDATE products p JOIN pricing_rules r ON p.id = r.product_id SET p.price = r.new_price WHERE r.active = 1 AND p.stock > 0 - 生产环境务必加
WHERE限定条件，并在事务中执行，留好回滚依据
复杂业务规则真正难的不是语法，而是每条子查询背后的业务含义是否被准确翻译成 SQL 条件——比如“最近生效的规则”要对应 valid_to >= NOW() 还是 valid_from ，漏掉一个边界就可能批量调错价。
