标量子查询是CPU飙升的隐形推手，因其逐行执行机制导致执行次数随主表行数指数级增长，如10万行主表触发500亿次扫描，且重复计算、无缓存、无法预聚合，严重违背批量处理原则。
标量子查询是CPU飙升的隐形推手，不是因为单次慢，而是因为它会指数级放大执行次数。
标量子查询的逐行执行机制
它不像普通JOIN或子查询那样一次性计算、批量关联，而是在主查询返回的每一行上，都重新执行一遍子查询。比如主表有10万行，子查询里又涉及一张50万行的订单明细表，那实际执行次数就是10万 × 50万 = 500亿次扫描——这还没算索引查找开销。
常见错误现象：SELECT id, (SELECT COUNT(*) FROM order_items WHERE order_id = o.id) AS item_cnt FROM orders o 这类写法在orders表超过几千行后，CPU使用率就会明显跳升，EXPLAIN里看不到明显全表扫描，但Rows_examined却高得离谱。
- 只要主查询结果集变大，子查询就成倍重复执行，完全违背批量处理原则
- 数据库无法对子查询做预聚合或物化，每次都要从头解析、优化、执行
- 如果子查询含
GROUP BY或ORDER BY，还会触发临时表和文件排序，进一步吃CPU
重复计算 + 缺乏缓存导致双重浪费
同一个order_id可能在主查询中出现多次（比如关联了用户、地址等多张表），而标量子查询不会自动缓存上次结果，每次遇到都重算一遍。这既违反DRY原则，又让CPU反复做相同工作。
使用场景：报表SQL、后台导出、定时任务中频繁出现；开发常误以为“逻辑清晰”就等于“性能友好”，其实只是把复杂度藏在了语法糖里。
- ORM生成的SQL（如Django的
annotate()未指定Subquery优化）容易产出这类结构 - MySQL 5.7+虽有
subquery cache机制，但只对完全相同的文本生效，参数化查询基本不命中 - PostgreSQL和SQL Server更不缓存标量子查询结果，纯靠执行计划复用，效果有限
NOT IN / 相关子查询加剧执行计划劣化
当标量子查询嵌套在WHERE条件中，尤其是NOT IN (SELECT ...)这种结构，优化器很容易放弃使用索引，转而选择嵌套循环或哈希半连接，甚至因子查询返回NULL导致整个条件失效——此时CPU已在无效计算上空转。
性能/兼容性影响：MySQL 8.0对NOT IN做了部分优化，但一旦子查询含JOIN或OR，依然大概率退化；SQL Server中NOT EXISTS比NOT IN稳定得多，但标量形式仍难逃逐行之苦。
- 子查询里若含
GETDATE()、RAND()等非确定性函数，彻底禁用任何缓存和计划复用 - 统计信息过期时，优化器可能低估子查询结果集大小，选错驱动表，让本该小表驱动的嵌套循环变成大表驱动
- 参数化查询中传入
NULL值，可能让标量子查询返回NULL，进而使外层=比较永远为UNKNOWN，触发大量无意义扫描
真正棘手的点不在语法本身，而在于它太隐蔽——EXPLAIN看不出执行次数膨胀，监控里只显示“单条SQL慢”，但实际是CPU被无数个微小的子查询碎片持续啃食。替换为LEFT JOIN预聚合或CTE物化，往往能直接砍掉90%以上CPU消耗。
