WITH 可提升SQL可读性与维护性，通过命名中间结果避免多层嵌套括号；需注意版本兼容（MySQL 5.7不支持）、别名冲突、字段限定、标量子查询性能陷阱及视图嵌套限制等问题。
用 WITH 替代 FROM 里的多层括号嵌套
直接把 FROM (SELECT ... FROM (SELECT ...) t1) t2 这种写法换成 WITH，可读性立刻翻倍。数据库不是靠缩进识别逻辑的，而是靠命名——WITH 给每一段中间结果起个名字，比如 recent_orders、active_users，后续引用时语义一目了然。
常见错误现象：嵌套三层后改一个 WHERE 条件，得来回数括号、核对别名，稍有不慎就漏掉一层，导致结果集错乱或 Unknown column 报错。
- 每个
WITH子句只做一件事，比如聚合、过滤、去重，不塞多个逻辑 - 子句之间按依赖顺序定义，后定义的可以引用前面的，但不能反着来
- 别在
WITH里写ORDER BY或LIMIT（除非是分页场景），它们对中间结果无意义，还可能被优化器忽略 - MySQL 5.7 不支持
WITH，会报ERROR 1235 (42000)；确认版本再用
派生表别名必须带明确前缀，禁止复用外层表别名
嵌套里写 SELECT * FROM users u，外层也用 u，数据库不会报错，但 u.id 到底指哪张 users？人眼难辨，执行计划更难查。这种别名冲突是静默陷阱，结果偏差往往要上线后才暴露。
使用场景：当你需要在 FROM 子句里套一个聚合结果，又得和外层 users 关联时。
- 外层用
u，子查询里就用u_sub或u_derived - 所有字段引用都加表别名限定，比如
u_sub.created_at，不写裸列名 - 如果子查询返回字段和外层同名（如都叫
id），必须显式AS重命名，否则SELECT *会错序
标量子查询别硬塞进 FROM，该 JOIN 就 JOIN
有人为了“一行一结果”，把 (SELECT COUNT(*) FROM orders WHERE user_id = u.id) 这种标量写进 SELECT 列表，再配合 FROM users u —— 表面简洁，实则性能黑洞。尤其当 users 有十万行，这个子查询就执行十万次。
更稳的路是提前算好，用派生表 + JOIN：
SELECT u.name, COALESCE(o.order_cnt, 0) AS order_cnt FROM users u LEFT JOIN ( SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id ) o ON u.id = o.user_id
- 标量子查询只适合低频、小范围、强关联的场景（比如查当前用户角色）
- 涉及聚合、GROUP BY、或需多次引用中间结果，一律改用派生表或
WITH -
LEFT JOIN后记得用COALESCE处理 NULL，否则业务层容易空指针
MySQL 创建视图时 FROM 嵌套直接报 ERROR 1349，绕不开就拆
MySQL 视图不支持 FROM 里有子查询，这是引擎限制，不是语法错。你写得再对，CREATE VIEW v AS SELECT ... FROM (SELECT ...) t 也会卡在 ERROR 1349 (HY000)。
解决思路不是硬扛，而是拆解：
- 把内层子查询单独建为一个视图（只要它本身不嵌套），再让外层视图基于这个视图构建
- 或者改用临时表（
CREATE TEMPORARY TABLE）预存中间结果，但注意生命周期和权限 - 应用层分两步查：先查聚合结果，再用结果集 ID 列表去查主表，用内存组合
- 确认 MySQL 版本 ≥ 8.0 再考虑
WITH，否则老版本只能靠物化中间结果或重构逻辑
复杂点永远不在语法是否合法，而在数据边界上——比如某用户没订单，派生表里就没有对应行，INNER JOIN 会丢人，LEFT JOIN 又得处理 NULL，这些都得在 WITH 或子查询的字段定义里提前想清楚。
