标量子查询在select中每行重复执行导致cpu飙升；应改用窗口函数avg(score) over (partition by student_id)或预聚合join，同时确保关联字段有索引，避免全表扫描和临时表开销。
标量子查询在SELECT里反复执行，CPU就在原地打转
比如 SELECT name, (SELECT AVG(score) FROM scores WHERE student_id = t.id) AS avg_score FROM students t，数据库对 students 每一行都重新跑一遍子查询——不是“执行一次缓存结果”，而是解析、计划、扫描、聚合全来一遍。CPU花在重复上下文切换和临时结果集构建上，而不是算力本身。
- 立刻改用窗口函数：
AVG(score) OVER (PARTITION BY student_id)，语义等价但零重复执行 - 或预聚合后
JOIN：SELECT t.name, a.avg_score FROM students t JOIN (SELECT student_id, AVG(score) avg_score FROM scores GROUP BY student_id) a ON t.id = a.student_id - SQL Server 2022+ 或金仓 V009R002C014+ 可能自动消除标量子查询，但必须检查执行计划里是否还有
Compute Scalar节点；有就说明没优化掉
WHERE里多层IN/EXISTS嵌套，触发Nᵏ级扫描
像 WHERE CustomerID IN (SELECT CustomerID FROM Customers WHERE City IN (SELECT City FROM Suppliers WHERE Country = 'USA')) 这类写法，最内层返回 200 个 City，中间层就要扫 200 次 Customers 表，外层再对每个匹配的 CustomerID 扫 Orders——这不是理论复杂度，是真实发生的 CPU 暴增。
- 必须拆成显式链式
JOIN：从Suppliers → Customers → Orders顺序连接，让优化器有机会走索引嵌套循环（Index Nested-Loop Join） - 确保每层连接字段都有索引：
Suppliers.Country、Customers.City、Orders.CustomerID至少是单列索引，复合索引更优 - 禁止
SELECT *，只取必要字段，否则Join Buffer溢出会退化为磁盘排序，CPU 和 I/O 一起拉高
视图嵌套超3层，优化器直接放弃代价估算
MySQL 5.7 及以前默认不合并视图，哪怕你只查 v_orders_summary.user_id，也会先完整执行整个四层嵌套定义再过滤；SQL Server 和 PostgreSQL 在深层嵌套下也常选错连接顺序——EXPLAIN 显示 type=ALL 或预估行数暴涨，就是典型信号。
- 优先把视图逻辑平铺成
JOIN，尤其当内部出现WHERE ... IN (SELECT ...)或多层SELECT * FROM (SELECT ...)时 -
CTE不是万能解药：只用一次、无参数、逻辑简单，直接写JOIN更轻量；只有中间结果被引用 ≥2 次，或需传参（如@start_date），才值得用WITH - MySQL 8.0.23+ 可加
MATERIALIZED强制物化，但必须显式声明字段名，SELECT *在跨版本迁移时极易因列序变化导致错位
关联子查询没走索引，退化成全表扫
例如 WHERE score > (SELECT AVG(score) FROM scores s2 WHERE s2.class_id = s1.class_id)，如果 scores.class_id 没索引，外层每行都会触发一次 scores 全表扫描——CPU 实际耗在磁盘 I/O 等待和逐行过滤上，而非计算。
- 检查执行计划：该子查询若显示
Table Scan或Clustered Index Scan，必须加索引 - 考虑用
CTE预聚合：WITH class_avg AS (SELECT class_id, AVG(score) avg_s FROM scores GROUP BY class_id)，再JOIN，避免重复计算 - PostgreSQL 12+ 和 MySQL 8.0+ 支持
LATERAL JOIN，语义更清晰且更容易命中索引，但注意语法兼容性
真正卡住性能的往往不是“嵌套”这个语法结构，而是嵌套背后缺失的索引、未预估的数据膨胀、以及优化器被迫选择低效路径——这些细节一旦漏查，换写法也白搭。
